No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, electronic, photocopying, recording, or otherwise, without prior written permission of Apple Computer, Inc. Printed in the United States of America.
No licenses, express or implied, are granted with respect to any of the technology described in this book. Apple retains all intellectual property rights associated with the technology described in this book. This book is intended to assist application developers to develop applications only for Apple Macintosh computers.
Every effort has been made to ensure that the information in this manual is accurate. Apple is not responsible for printing or clerical errors.
Apple Computer, Inc.
20525 Mariani Avenue
Cupertino, CA 95014
408-996-1010
Apple, the Apple logo, APDA, AppleLink, AppleShare, A/UX, HyperCard, LaserWriter, Macintosh, Macintosh Quadra, MPW, PowerBook, and SANE are trademarks of Apple Computer, Inc., registered in the United States and other countries.
Finder, Macintosh Centris, QuickDraw, and QuickTime are trademarks of Apple Computer, Inc.
Adobe Illustrator and PostScript are trademarks of Adobe Systems Incorporated, which may be registered in certain jurisdictions.
America Online is a service mark of Quantum Computer Services, Inc.
Classic is a registered trademark licensed to Apple Computer, Inc.
CompuServe is a registered service mark of CompuServe, Inc.
FrameMaker is a registered trademark of Frame Technology Corporation.
Helvetica and Palatino are registered trademarks of Linotype Company.
Internet is a trademark of Digital Equipment Corporation.
ITC Zapf Dingbats is a registered trademark of International Typeface Corporation.
Motorola is a registered trademark of Motorola Corporation.
Optrotech is a trademark of Orbotech Corporation.
PowerPC is a trademark of International Business Machines Corporation.
THINK C is a trademark of Symantec Corporation.
UNIX is a registered trademark of UNIX System Laboratories, Inc.
Simultaneously published in the United States and Canada.
LIMITED WARRANTY ON MEDIA AND REPLACEMENT
ALL IMPLIED WARRANTIES ON THIS MANUAL, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF THE ORIGINAL RETAIL PURCHASE OF THIS PRODUCT.
Even though Apple has reviewed this manual, APPLE MAKES NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS MANUAL, ITS QUALITY, ACCURACY, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS MANUAL IS SOLD “AS IS,” AND YOU, THE PURCHASER, ARE ASSUMING THE ENTIRE RISK AS TO ITS QUALITY AND ACCURACY.
IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS MANUAL, even if advised of the possibility of such damages.
THE WARRANTY AND REMEDIES SET FORTH ABOVE ARE EXCLUSIVE AND
IN LIEU OF ALL OTHERS, ORAL OR WRITTEN, EXPRESS OR IMPLIED. No Apple dealer, agent, or employee is authorized to make any modification, extension, or addition to this warranty.
Some states do not allow the exclusion or limitation of implied warranties or liability for incidental or consequential damages,
so the above limitation or exclusion may
not apply to you. This warranty gives you specific legal rights, and you may also have other rights which vary from state to state.
ISBN 0-201-40727-2
1 2 3 4 5 6 7 8 9-CRW-9897969594
First Printing, February 1994
Library of Congress Cataloging-in-Publication Data
Inside Macintosh. PowerPC system software / Apple Computer, Inc.
p.cm.
Includes index.
ISBN 0-201-40727-2
1. Macintosh (Computer)2. PowerPC (Microprocessor)3. Systems
software.I. Title: PowerPC system software.
QA76.8.M3I5281994
005.4'469—dc20 93-50182
CIP
Contents
Figures, Tables, and Listingsvii
Preface About This Bookix
Related Documentationxi
Format of a Typical Chapterxi
Conventions Used in This Bookxii
Special Fontsxii
Types of Notesxii
Bit Numbering and Word Sizexii
Assembly-Language Informationxiv
Development Environmentxiv
For More Informationxv
Chapter 1 Introduction to PowerPC System Software1-1
Overview of the PowerPC System Software1-4
The 68LC040 Emulator1-6
Emulator Operation1-7
Emulator Limitations1-8
Coprocessors1-9
Instruction Timings1-9
Deleted Instructions1-9
Unsupported Instruction Features1-10
Instruction Caches1-10
Address Error Exceptions1-10
Bus Error Exceptions1-11
Memory-Mapped I/O Locations1-11
Mixed Mode1-13
Cross-Mode Calls1-14
Routine Descriptors1-15
Memory Considerations1-19
The PowerPC Native Environment1-19
Fragments1-20
The Structure of Fragments1-22
Imports and Exports1-23
The Table of Contents1-26
Special Routines1-29
Fragment Storage1-30
Executable Resources1-34
Calling Conventions1-41
The 680x0 Calling Conventions1-42
The PowerPC Calling Conventions1-43
Parameter Passing1-47
Import Libraries1-50
The Organization of Memory1-52
File Mapping1-53
The System Partition1-56
Application Partitions1-57
Data Alignment1-63
Compatibility and Performance1-65
Patches1-66
The Memory Manager1-68
Performance Tuning1-70
Mode Switches1-71
Routine Parameters1-72
Chapter 2 Mixed Mode Manager2-1
About the Mixed Mode Manager2-4
External Code2-4
Procedure Pointers2-5
Mode Switches2-7
Calling PowerPC Code From 680x0 Code2-8
Calling 680x0 Code From PowerPC Code2-12
Using the Mixed Mode Manager2-14
Specifying Procedure Information2-14
Using Universal Procedure Pointers2-21
Using Static Routine Descriptors2-22
Executing Resource-Based Code2-24
Mixed Mode Manager Reference2-26
Constants2-27
Routine Descriptor Flags2-27
Procedure Information2-27
Routine Flags2-34
Instruction Set Architectures2-35
Data Structures2-36
Routine Records2-36
Routine Descriptors2-37
Mixed Mode Manager Routines2-38
Creating and Disposing of Routine Descriptors2-39
Calling Routines via Universal Procedure Pointers2-42
Determining Instruction Set Architectures2-44
Summary of the Mixed Mode Manager2-45
C Summary2-45
Constants2-45
Data Types2-48
Mixed Mode Manager Routines2-49
Chapter 3 Code Fragment Manager3-1
About the Code Fragment Manager3-3
Fragments3-4
Import Library Searching3-5
Version Checking3-7
Using the Code Fragment Manager3-10
Loading Code Fragments3-10
Creating a Code Fragment Resource3-12
Getting Information About Exported Symbols3-14
Code Fragment Manager Reference3-15
Data Structures3-15
Fragment Initialization Block3-15
Fragment Location Record3-16
Memory Location Record3-17
Disk Location Record3-17
Segment Location Record3-18
Code Fragment Manager Routines3-18
Loading Fragments3-19
Unloading Fragments3-23
Finding Symbols3-24
Fragment-Defined Routines3-26
Resources3-28
The Code Fragment Resource3-28
Summary of the Code Fragment Manager3-32
C Summary3-32
Constants3-32
Data Types3-33
Code Fragment Manager Routines3-34
Fragment-Defined Routines3-35
Result Codes3-35
Chapter 4 Exception Manager4-1
About the Exception Manager4-3
Exception Contexts4-4
Types of Exceptions4-5
Using the Exception Manager4-6
Installing an Exception Handler4-6
Writing an Exception Handler4-7
Exception Manager Reference4-9
Constants4-9
Exception Kinds4-9
Memory Reference Kinds4-11
Data Structures4-12
Machine Information Records4-12
Register Information Records4-12
Floating-Point Information Records4-14
Memory Exception Records4-15
Exception Information Records4-16
Exception Manager Routines4-17
Application-Defined Routines4-17
Summary of the Exception Manager4-19
C Summary4-19
Constants4-19
Data Types4-19
Exception Manager Routines4-22
Application-Defined Routines4-22
GlossaryGL-1
IndexIN-1
Figures, Tables, and Listings
Preface About This Bookix
Figure P-1 680x0 bit numberingxiii
Figure P-2 PowerPC bit numberingxiii
Table P-1 Sizes of memory operandsxiii
Chapter 1 Introduction to PowerPC System Software1-1
Figure 1-1 The system software for PowerPC processor-based Macintosh computers1-5
Figure 1-2 Creating imports in a fragment1-24
Figure 1-3 A transition vector1-27
Figure 1-4 The structure of a PowerPC application1-31
Figure 1-5 The structure of a 680x0 application1-32
Figure 1-6 The structure of a fat application1-33
Figure 1-7 The structure of an accelerated resource1-35
Figure 1-8 The structure of a private resource1-36
Figure 1-9 A 680x0 stack frame1-42
Figure 1-10 The PowerPC stack1-44
Figure 1-11 The structure of a stack frame’s linkage area1-45
Figure 1-12 The Red Zone1-46
Figure 1-13 The organization of the parameter area on the stack1-49
Figure 1-14 Organization of memory when virtual memory is enabled1-54
Figure 1-15 Organization of memory when virtual memory is not enabled1-56
Figure 1-16 The structure of a PowerPC application partition1-60
Figure 1-17 The Memory control panel for PowerPC processor-based Macintosh computers1-69
Listing 1-1 Creating a routine descriptor1-17
Listing 1-2 The definition of the NewControlActionProc routine1-18
Listing 1-3 Creating a routine descriptor for a control action procedure1-19
Listing 1-4 Testing for unresolved soft imports1-25
Listing 1-5 The Rez input for a sample 'cfrg' resource1-32
Listing 1-6 Rez input for a list definition procedure stub1-35
Listing 1-7 Using an accelerated resource1-37
Listing 1-8 Some acceptable global declarations in an accelerated resource1-39
Listing 1-9 Some unacceptable global declarations and code in an accelerated resource1-39
Listing 1-10 Using a private resource1-40
Listing 1-11 Declaring an application’s QuickDraw global variables1-59
Listing 1-12 A sample 680x0 VBL task definition1-61
Listing 1-13 A conditionalized VBL task definition1-62
Listing 1-14 Patching an Operating System trap1-67
Listing 1-15 Waiting to call the WaitNextEvent function1-72
Chapter 2 Mixed Mode Manager2-1
Figure 2-1 680x0 and PowerPC procedure pointers2-5
Figure 2-2 Calling PowerPC code from a 680x0 application2-9
Figure 2-3 The stack before a mode switch2-10
Figure 2-4 A 680x0-to-PowerPC switch frame2-11
Figure 2-5 A PowerPC-to-680x0 switch frame2-13
Figure 2-6 Procedure information for a stack-based routine2-17
Figure 2-7 Procedure information for a register-based routine2-19
Figure 2-8 General structure of an executable code resource2-25
Figure 2-9 General structure of a fat resource2-26
Table 2-1 Limits on the number of specifiable parameters in a procedure information2-20
Listing 2-1 Sample glue code for a 680x0 routine2-12
Listing 2-2 Creating global routine descriptors2-21
Listing 2-3 Creating local routine descriptors2-22
Listing 2-5 Building a static routine descriptor2-23
Chapter 3 Code Fragment Manager3-1
Figure 3-1 Structure of a compiled code fragment ('cfrg') resource3-29
Figure 3-2 The format of a code fragment information record3-30
Listing 3-1 Pseudocode for the version-checking algorithm3-9
Listing 3-2 Loading a resource-based fragment3-11
Listing 3-3 Loading a disk-based fragment3-11
Listing 3-4 The Rez input for a typical application’s 'cfrg' resource3-12
Listing 3-5 The Rez input for a typical import library’s 'cfrg' resource3-13
Listing 3-6 Finding symbol names3-14
Chapter 4 Exception Manager4-1
Listing 4-1 Installing an exception handler4-6
Listing 4-2 A native exception handler4-8
About This Book
This book, Inside Macintosh: PowerPC System Software, describes the new process execution environment and system software services provided with the first version of the system software for Macintosh on PowerPC computers. It contains information you need to know to write applications and other software that can run on PowerPC processor-based Macintosh computers.
The first release of the system software for Macintosh on PowerPC computers provides a mixed or hybrid environment: the system software provides the ability to execute both applications that use the native instruction set of the PowerPC microprocessor and applications that use the 680x0 instruction set. It accomplishes this by providing a very efficient 68LC040 Emulator that emulates 680x0 instructions with PowerPC instructions. As a result, virtually all existing 680x0-based Macintosh applications and other software modules that conform to the programming interfaces and techniques documented in the Inside Macintosh suite of books will execute without modification on PowerPC processor-based Macintosh computers.
To take maximum advantage of the much greater processing speed of the PowerPC microprocessor, however, you’ll need to recompile your application’s source code into a PowerPC application. Apple Computer, Inc., provides MPW-based C and C++ compilers and other tools that you can use to create native PowerPC applications. In general, if your source code is already compliant with ANSI C standards or the de facto ANSI C++ standards, you should be able, with moderately little effort, to rework your source code so that it can be compiled and built using the Apple-supplied tools into a PowerPC application. This book is intended to provide much of the information you need to port your existing 680x0 application (or other software) to the PowerPC platform.
Note
There will also be third-party compilers and development
environments capable of generating PowerPC code.u
Although the native run-time execution environment of the first version of the system software for PowerPC processor-based Macintosh computers is significantly different from the execution environment of current 680x0-based Macintosh computers, you won’t need to worry about those differences unless your existing code relies on specific information about the 680x0 execution environment. For example, if for some reason you directly access information in your application’s A5 world, you’ll need to rewrite those
parts of code when porting your application to the PowerPC environment. Similarly, you’ll need to rewrite any parts of your code that depend on
data being passed in certain 680x0 registers. VBL tasks, for instance, very often depend on the fact that a pointer to the VBL task record is passed in register A0.
The first chapter in this book, “Introduction to PowerPC System Software,” provides a general overview of the system software that runs on PowerPC processor-based Macintosh computers. It also describes in detail the mixed environment provided by the 68LC040 Emulator and the Mixed Mode Manager, as well as the new run-time environment used for native PowerPC applications. You should read this chapter for general information about porting your existing software to the PowerPC environment. Even if you do not intend to port your existing 680x0 software, you might still want to read this chapter for information about running under the 68LC040 Emulator.
The remaining chapters in this book provide reference material for the three new system software managers introduced in the first version of the system software for PowerPC processor-based Macintosh computers. You should read these chapters for specific information on using the services provided by those managers. The new system software managers are
n the Mixed Mode Manager, which manages the mixed environment of PowerPC processor-based Macintosh computers running 680x0-based code
n the Code Fragment Manager, which loads fragments (blocks of executable PowerPC code and their associated data) into memory and prepares them for execution
n the Exception Manager, which handles exceptions that occur during the execution of PowerPC applications or other software
IMPORTANT
Some of the system software services introduced in the first version of the system software for PowerPC processor-based Macintosh computers might in the future be available on Macintosh computers that are not based on the PowerPC microprocessor. For example, it’s possible that the Code Fragment Manager (and the entire run-time environment based on fragments) will be included in future versions of the system software for 680x0-based Macintosh computers. As a result, some of the information in this book might eventually be more generally applicable than the title of this book might suggest.s
If you are new to programming for Macintosh computers, you should read the book Inside Macintosh: Overview for an introduction to general concepts
of Macintosh programming. You should also read other books in the Inside Macintosh series for specific information about other aspects of the Macintosh Toolbox and the Macintosh Operating System. In particular, to benefit most from this book, you should already be familiar with the run-time environment of 680x0 applications, as described in the two books Inside Macintosh: Processes and Inside Macintosh: Memory.
Related Documentation
This book is part of a larger suite of books that contain information essential for developing PowerPC applications and other software.
n For information about the PPCC compiler that you can use to compile your source code into a PowerPC application, see the book C/C++ Compiler for Macintosh With PowerPC.
n For information about the PPCAsm assembler, see the book Assembler for Macintosh With PowerPC.
n For information about debugging and measuring the performance of PowerPC applications, see the book Macintosh Debugger Reference.
n For information about performing floating-point calculations in PowerPC applications, see the book Inside Macintosh: PowerPC Numerics.
n For information about building PowerPC applications and other kinds of PowerPC software for Macintosh computers, see Building Programs for Macintosh With PowerPC.
Format of a Typical Chapter
Almost all chapters in this book follow a standard structure. For example, the chapter “Mixed Mode Manager” contains these sections:
n “About the Mixed Mode Manager.” This section describes the Mixed Mode Manager. You should read this section for a general understanding of
what the Mixed Mode Manager does and when you might need to call
it explicitly.
n “Using the Mixed Mode Manager.” This section provides detailed instruc-
tions on using the Mixed Mode Manager. You should read this section if you need to use the services provided by the Mixed Mode Manager.
n “Mixed Mode Manager Reference.” This section provides a complete reference to the constants, data structures, and routines provided by the Mixed Mode Manager. Each routine description also follows a standard format, which presents the routine declaration followed by a description
of every parameter of the routine. Some routine descriptions also give additional descriptive information, such as circumstances under which you cannot call the routine or result codes.
n “Summary of the Mixed Mode Manager.” This section provides the C interfaces for the constants, data structures, routines, and result codes associated with the Mixed Mode Manager.
Conventions Used in This Book
Inside Macintosh uses various conventions to present information. Words that require special treatment appear in specific fonts or font styles. Certain information, such as parameter blocks, appears in special formats so that you can scan it quickly.
Special Fonts
All code listings, reserved words, and the names of actual data structures, constants, fields, parameters, and routines are shown in Courier (this is Courier).
Words that appear in boldface are key terms or concepts and are defined in the glossary at the end of this book. Note that numerical entries (for example, 32-bit clean) are sorted before all alphabetical entries in the glossary and in the index.
Types of Notes
There are several types of notes used in Inside Macintosh.
Note
A note like this contains information that is interesting but possibly not essential to an understanding of the main text. (An example appears on page 1-6.)u
IMPORTANT
A note like this contains information that is essential for an understanding of the main text. (An example appears on page 1-19.)s
sWARNING
Warnings like this indicate potential problems that you should be aware of as you design your application. Failure to heed these warnings
could result in system crashes or loss of data. (An example appears on page 1-8.)s
Bit Numbering and Word Size
This book departs from the conventions followed in previous Inside Macintosh books in regard to the numbering of bits within a range of data. Previously, for example, the bits in a 32-bit data type were numbered 0 to 31, from right to left, as shown in Figure P-1 on the following page. The least significant bit of a 32-bit data type was addressed as bit 0, and the most significant bit was addressed as bit 31. This convention was in accordance with that used by Motorola in the books documenting their 680x0 family of microprocessors (for example, the MC68040 32-Bit Microprocessor User’s Manual).
Figure P-1 680x0 bit numbering
In this book, the bits in a 32-bit data type are numbered 0 to 31, from left to right. The most significant bit of a 32-bit data type is addressed as bit 0, and the least significant bit is addressed as bit 31. This convention, illustrated in Figure P-2, is in accordance with the bit-numbering conventions used by Motorola in the books documenting the PowerPC family of microprocessors (for example, the PowerPC 601 RISC Microprocessor User’s Manual).
Figure P-2 PowerPC bit numbering
In addition, there are differences between 680x0 and the PowerPC terminology to describe the sizes of certain memory operands, as shown in Table P-1.
Table P-1 Sizes of memory operands
Size 680x0 terminology PowerPC terminology
8 bits Byte Byte
2 bytes Word Half word
4 bytes Long word Word
8 bytes N/A Double word
16 bytes N/A Quad word
To avoid confusion, however, this book generally uses bytes to give the sizes of objects in memory.
Assembly-Language Information
Inside Macintosh presents information about the fields of a parameter block in this format:
The arrow in the far-left column indicates whether the field is an input parameter, output parameter, or both. You must supply values for all input parameters and input/output parameters. The routine returns values in output parameters and input/output parameters.
The second column shows the field name as defined in the MPW C interface files; the third column indicates the C data type of that field. The fourth column provides a brief description of the use of the field. For a complete description of each field, see the discussion that follows the parameter
block or the description of the parameter block in the reference section of
the chapter.
Development Environment
The system software routines described in this book are available using C
or assembly-language interfaces. How you access these routines depends
on the development environment you are using. This book shows system software routines in their C interface using the Macintosh Programmer’s Workshop (MPW).
All code listings in this book are shown in C (except for listings that describe resources, which are shown in Rez-input format). They show methods of using various routines and illustrate techniques for accomplishing particular tasks. All code listings have been compiled and, in most cases, tested. However, Apple Computer does not intend that you use these code samples in your application. You can find the location of this book’s code listings in the list of figures, tables, and listings.
To make the code listings in this book more readable, only limited error handling is shown. You need to develop your own techniques for detecting and handling errors.
This book occasionally illustrates concepts by reference to a sample applica-
tion called SurfWriter and a sample import library called SurfTools; these are not actual products of Apple Computer, Inc.
For More Information
APDA is Apple’s worldwide source for over three hundred development tools, technical resources, training products, and information for anyone interested in developing applications on Apple platforms. Customers receive the quarterly APDA Tools Catalog featuring all current versions of Apple development tools and the most popular third-party development tools. Ordering is easy; there are no membership fees, and application forms are not required for most of our products. APDA offers convenient payment and shipping options, including site licensing.
To order products or to request a complimentary copy of the APDA Tools Catalog, contact
APDA
Apple Computer, Inc.
P.O. Box 319
Buffalo, NY 14207-0319Telephone 800-282-2732 (United States)
800-637-0029 (Canada)
716-871-6555 (International)
Fax 716-871-6511
AppleLink APDA
America Online APDA
CompuServe 76666,2405
Internet APDA@applelink.apple.com
If you provide commercial products and services, call 408-974-4897 for information on the developer support programs available from Apple.
For information on registering signatures, file types, Apple events, and other technical information, contact
Macintosh Developer Technical Support
Apple Computer, Inc.
20525 Mariani Avenue, M/S 303-2T
Cupertino, CA 95014-6299
Listing 1-0
Table 1-0
Introduction to PowerPC System Software
Contents
Overview of the PowerPC System Software1-4
The 68LC040 Emulator1-6
Emulator Operation1-7
Emulator Limitations1-8
Coprocessors1-9
Instruction Timings1-9
Deleted Instructions1-9
Unsupported Instruction Features1-10
Instruction Caches1-10
Address Error Exceptions1-10
Bus Error Exceptions1-11
Memory-Mapped I/O Locations1-11
Mixed Mode1-13
Cross-Mode Calls1-14
Routine Descriptors1-15
Memory Considerations1-19
The PowerPC Native Environment1-19
Fragments1-20
The Structure of Fragments1-22
Imports and Exports1-23
The Table of Contents1-26
Special Routines1-29
Fragment Storage1-30
Executable Resources1-34
Calling Conventions1-41
The 680x0 Calling Conventions1-42
The PowerPC Calling Conventions1-43
Parameter Passing1-47
Import Libraries1-50
The Organization of Memory1-52
File Mapping1-53
The System Partition1-56
Application Partitions1-57
Data Alignment1-63
Compatibility and Performance1-65
Patches1-66
The Memory Manager1-68
Performance Tuning1-70
Mode Switches1-71
Routine Parameters1-72
Introduction to PowerPC System Software
This chapter is a general introduction to the system software provided on PowerPC processor-based Macintosh computers. It describes the mixed environment provided by the 68LC040 Emulator and the Mixed Mode Manager. These two new system software services work together to allow existing 680x0 applications, extensions, drivers, and other software to execute without modification on PowerPC processor-based Macintosh computers. The 68LC040 Emulator and the Mixed Mode Manager also make it possible for parts of the system software to remain as 680x0 code, while other parts of the system software are reimplemented (primarily for reasons of speed) as native PowerPC code.
This chapter also describes the native PowerPC execution environment. Although the process-scheduling mechanism used for both native and emulated applications has not changed, the run-time environment for PowerPC applications is significantly different from the run-time environment used for 680x0-based Macintosh applications. In cases where your application (or other software) relies on features of the 680x0 run-time environment, you’ll need to modify your application before recompiling it as a PowerPC application. For example, if your application directly accesses information stored in low memory (such as system global variables) or in its A5 world, you might need to rewrite parts of your application to remove the dependence on that information. See “The PowerPC Native Environment” beginning on page 1-19 for complete instructions on doing this.
You should read this chapter if you want your application to run on PowerPC processor-
based Macintosh computers, either under the 68LC040 Emulator or in the PowerPC native environment. If you choose not to rebuild your application for the PowerPC environment, you should at least make certain that it doesn’t violate any of the known restrictions on the emulator. See “Emulator Limitations” on page 1-8 for specific informa-
tion about the known operational differences between the 68LC040 Emulator and a 680x0 microprocessor.
You should also read this chapter for information about the PowerPC execution environ-
ment. Although the existing software development tools build your source code into executable PowerPC code that conforms to the requirements of this new environment, you might need to know about the native run-time environment for debugging purposes or if your application uses external code modules. Otherwise, the new execution environ-
ment should be completely transparent to your application.
You should be able to accomplish much of the work involved in porting your application from the 680x0 platform to the PowerPC platform using the information in this chapter. If your application installs callback routines with nonstandard calling conventions, however, you might need to read the chapter “Mixed Mode Manager” in this book. In addition, if your application explicitly loads external code modules (such as file trans-
lators or custom definition procedures), you might need to read the chapter “Code Fragment Manager” in this book. Read the chapter “Exception Manager” if you want your native application to handle any exceptions that arise while it is executing.
To use this chapter, you should already be generally familiar with the Macintosh Operating System. See the books Inside Macintosh: Processes and Inside Macintosh: Memory for information about the run-time environment of 680x0-based Macintosh computers.
This chapter begins with a description of the mixed environment provided by the PowerPC system software. Then it gives information about the native PowerPC run-time environment. This chapter ends by explaining how to perform a number of specific
tasks in the PowerPC environment, such as patching system software traps.
Note
For ease of exposition, this book occasionally focuses on porting applications from the 680x0 environment to the PowerPC environment. In general, however, any changes required for applications are required also for all other kinds of software.u
Overview of the PowerPC System Software
The system software for PowerPC processor-based Macintosh computers is System 7.1, with suitable changes made to support the mixed environment that allows both 680x0 software and PowerPC software to execute on a computer. The mixed environment provides virtually complete compatibility for existing 680x0 software, as well as vastly increased performance for applications and other software that are built to use the native instruction set of the PowerPC microprocessor.
Because the system software for PowerPC processor-based Macintosh computers is derived from System 7.1 for 680x0-based Macintosh computers, your application—whether 680x0 or PowerPC—must conform to the basic requirements imposed by system software versions 7.0 and later. In particular, your application (or other software) must be
n 32-bit clean
n compatible with the operations of the Virtual Memory Manager
n able to operate smoothly in the cooperative multitasking environment maintained by the Process Manager
If your 680x0 software conforms to these specific requirements and to the general requirements for Macintosh software documented throughout Inside Macintosh, it is highly probable that it will execute without problems on PowerPC processor-based Macintosh computers. This is because the system software for PowerPC processor-based Macintosh computers includes a very efficient 68LC040 Emulator that emulates 680x0 instructions with PowerPC instructions. In addition, the system software includes the Mixed Mode Manager, which is responsible for handling any necessary mode switches between the native PowerPC environment and the 680x0 environment.
Figure 1-1 shows a general overview of the system software for PowerPC processor-
based Macintosh computers. A small kernel, called the nanokernel, communicates directly with the PowerPC processor and provides very low-level services (such as interrupt handling and memory management).
Figure 1-1 The system software for PowerPC processor-based Macintosh computers
Even applications written entirely in 680x0 code might cause mode switches while they are executing, because some portions of the Macintosh Operating System have been rewritten in PowerPC code for increased performance. For example, the Memory Manager has been rewritten in C and recompiled into PowerPC code. In general, however, mode switches occur completely transparently to 680x0 software. Only native PowerPC software needs to worry about mode switches. See “Mixed Mode” beginning on page 1-13 for details.
As you would expect, the emulation environment provided by the 68LC040 Emulator uses the standard 680x0 run-time model. The organization of an application partition and the run-time behavior of emulated software are identical to what is provided on 680x0-based Macintosh computers. However, the execution environment for native PowerPC software is significantly different from the standard 680x0 run-time environ-
ment. The PowerPC environment provides a much simpler and easier-to-use run-time model based on fragments. A fragment is any block of executable PowerPC code and its associated data. Fragments are created by your development system’s linker.
Note
Note
The term fragment is not intended to suggest that the block of code and data is in any way either small, detached, or incomplete. Fragments can be of virtually any size, and they are complete, executable entities. The term fragment was chosen to avoid confusion with the terms already used in Inside Macintosh to describe executable code (such as component and module).u
Fragments use a method of addressing the data they contain that is different and more general than the A5-relative method that 680x0 applications use to address their global data. One important consequence is that any PowerPC software packaged as a fragment has easy access to global data. In the 680x0-based system software, it was sometimes difficult to use global data within types of software other than applications.
In addition, it was often complicated for a routine installed by some code to gain
access to the code’s global variables. For example, you cannot—in the current 680x0 environment—write a VBL task that uses your application’s global variables without somehow passing your application’s A5 value to the VBL task. (A VBL task is a task that executes during a vertical blanking interrupt.) In the PowerPC environment, any routine contained in an application has automatic access to the application’s global variables. You do not need to devise special ways to pass the address of your application’s A5 world to the installed routine. More generally, any routine executing in the PowerPC environment has access to the global data of the fragment it’s contained in.
The new run-time model used for native PowerPC software incorporates other important simplifications as well. In native applications, there is no segmentation of
the executable code. The existing compilers that produce PowerPC code ignore any segmentation directives you include in your source code. In addition, any calls you make to the Segment Manager’s UnloadSeg procedure are simply ignored by the PowerPC system software. The task of keeping required code in memory is handled completely by the Virtual Memory Manager or the Process Manager, not by your application.
The remaining sections in this chapter describe in greater detail the mixed environment of PowerPC processor-based Macintosh computers and the new native run-time environment. If you’re interested mainly in rebuilding your application as native PowerPC code, you can skip to the section “Mixed Mode” beginning on page 1-13, which describes the ways in which you might need to use the Mixed Mode Manager
to make your native application compatible with the mixed environment.
The 68LC040 Emulator
The 68LC040 Emulator is the part of the PowerPC system software that allows 680x0 applications and other software to execute on PowerPC processor-based Macintosh computers. This emulator provides an execution environment that is virtually identical to the execution environment found on 680x0-based Macintosh computers. The emulator converts 680x0 instructions into PowerPC instructions, issues those instructions to the PowerPC microprocessor, and updates the emulated environment (such as the emulated 680x0 registers) in response to the operations of the PowerPC microprocessor.
In general, the 680x0 emulation environment supports all existing 680x0 applications that already work correctly on all Macintosh computers containing a Motorola 68020, 68030, or 68040 microprocessor. There are, however, some differences between the operation of the 68LC040 Emulator and an actual 68040 microprocessor. The following two sections provide some information on the general operation and limitations of the 68LC040 Emulator.
Note
Unless you are programming in assembly language or doing very low-level debugging, you’re not likely to need the information in
the following two sections.u
Emulator Operation
The 68LC040 Emulator implements the basic Motorola 68040 user mode instruction set. It does not, however, support any of the instructions from the optional 68881 or 68882 floating-point coprocessors. Moreover, although the emulator supports the operations of the Virtual Memory Manager, it does not support instructions from the 68851 Paged Memory Management Unit (PMMU). The 680x0-based Macintosh computer whose hardware configuration most closely resembles the software configuration of the 68LC040 Emulator is the Macintosh Centris 610, which contains the Motorola 68LC040 microprocessor. (The 68LC040 microprocessor is identical to the 68040 microprocessor except that it has no floating-point unit.) As a result, if your application or other software runs without problems on the Macintosh Centris 610, it is very likely to run without problems under the 68LC040 Emulator.
Note
For the complete specification of how you can expect both a
real 68040 and the 68LC040 Emulator to behave, see the
MC68040 32-Bit Microprocessor User’s Manual.u
The Gestalt function returns the value gestalt68020 when you pass it the selector gestaltProcessorType and the calling software is executing under the emulator. This return value is intended to highlight the two ways in which the 68LC040 Emulator more closely resembles a 68020 processor than a 68040 processor:
n The emulated environment does not support either the FPU or the MMU contained in an actual 68040 processor.
n The emulated environment creates exception stack frames in accordance with the 68020 exception frame model.
The 68LC040 Emulator consists of two main parts, a main dispatch table and a block of additional code called by entries in the main dispatch table. The main dispatch table contains two native PowerPC instructions for each recognized 680x0 operation code (or opcode). In cases where a 680x0 opcode can be handled by a single PowerPC instruction, the first native instruction in the dispatch table is enough to complete the requested operation. In most cases, however, the handling of a 680x0 opcode requires more than one PowerPC instruction. In that case, the first native instruction in the main dispatch table simply begins the emulation process.
The second native instruction in the emulator’s main dispatch table is usually a PC-relative branch into the block of additional code. The additional code continues
the emulation of the 680x0 opcode begun by the first instruction.
The emulator’s main dispatch table also includes entries that support private opcodes reserved for use by the system software, including both A-line and F-line instructions. For example, the Mixed Mode Manager communicates with the 68LC040 Emulator using A-line instructions embedded in routine descriptors. (See “Routine Descriptors” beginning on page 1-15 for details.) Other system software services, including the Virtual Memory Manager, also issue reserved opcodes to the emulator.
When the emulator is active, it maps all 680x0 registers to the registers on the PowerPC microprocessor, including the 680x0 program counter (PC) and Status Register (SR). The general-purpose register GPR1 serves as both the 680x0 and native stack pointer. The emulator also dedicates a native register to point to the 680x0 context block, a block
of data containing information that needs to be preserved across mode switches. The context block contains all the 680x0 registers, the addresses of the main dispatch table and the block of additional code, and other information used internally by the emulator. The emulator saves information into the context block when it is about to exit (for example, when a 680x0 application calls a piece of native code) and restores the information from the block when it is subsequently activated.
sWARNING
You should not rely on any specific information about the 68LC040 Emulator’s private data structures or opcodes.s
Emulator Limitations
Largely because it is a purely software implementation of a hardware microprocessor, the 68LC040 Emulator sometimes exhibits behavior that differs from that of an actual 680x0 microprocessor. These operational differences can lead to problems, ranging from the obvious (for example, using the floating-point coprocessor instruction set, which is not supported by the 68LC040 Emulator) to the subtle (for example, depending upon a value in an undefined condition code bit). If your application or other software depends on 680x0 behavior that is not reproduced exactly by the 68LC040 Emulator, your product might have problems when executing under the emulator. The known exceptions to the documented 680x0 specifications concern
n coprocessors and instruction sets
n instruction timings
n deleted instructions
n unsupported instruction features
n instruction caches
n address error exceptions
n bus error exceptions
n memory-mapped I/O locations
The following sections describe these limitations in greater detail.
Coprocessors
As previously indicated, the 68LC040 Emulator does not support the instruction sets of either the 68881 or the 68882 floating-point coprocessor or of the 68851 PMMU. Any software that uses floating-point instructions is therefore not compatible with the 68LC040 Emulator. Because there are several 680x0-based Macintosh computers that
do not contain floating-point coprocessors, this restriction is not likely to cause new compatibility problems for your software. It’s possible that you have used SANE to perform hardware-independent floating-point arithmetic. If so, you’ll probably notice that floating-point calculations are performed even faster under the 68LC040 Emulator than on a real 680x0-based Macintosh computer. This is because PowerPC processor-
based Macintosh computers include an accelerated version of SANE written in native PowerPC code.
The 68LC040 Emulator does not support the 68851 PMMU instruction set (which also includes the 68030 and 68040 internal PMMUs). The Virtual Memory Manager is still supported, but using a different mechanism. Very few applications address the PMMU directly, so this restriction is not likely to affect many developers. Those applications that do address the PMMU directly are very likely already incompatible with A/UX and with the Virtual Memory Manager.
More generally, the 68LC040 Emulator does not support the coprocessor bus interface. As a result, the emulator does not support any externally connected hardware coprocessors.
Instruction Timings
The 68LC040 Emulator executes 680x0 instructions as fast as possible, making no attempt to maintain the same number of clock counts as on a real 68040 microprocessor. There are classes of instructions that execute in the same number of cycles whether
on a real 68040 or under the 68LC040 Emulator, but you should not depend on this.
In general, of course, your 680x0 application is most likely already independent of instruction timing, because it should run without problem on a wide range of 680x0 microprocessors having quite different clock rates.
Deleted Instructions
Several instructions included in the instruction set of the 68020 microprocessor were removed from the instruction sets of the 68030 and 68040 microprocessors. The deleted instructions are the CALLM and RTM instructions, which were intended for use in module calls. These instructions are not supported by the 68LC040 Emulator, and any attempt
to execute them will result in an illegal instruction exception. However, because these instructions are not present in any 680x0 microprocessor either before or after the 68020, this restriction is not likely to present compatibility problems for your software.
Unsupported Instruction Features
Several instruction or addressing mode fields and encodings are documented by Motorola as reserved. In addition, many instructions are documented as producing undefined condition code result bits or undefined register results. Accordingly, the behavior of these reserved fields and undefined results differs across the various members of the 680x0 family of microprocessors and under the 68LC040 Emulator. It is unlikely that any existing software intentionally depends on either reserved fields or undefined results. It is, however, remotely possible that through a programming error some software might be depending on these results and hence might behave differently under the emulator than on an actual 680x0.
Instruction Caches
The operation of the instruction cache in the 68040 microprocessor is not supported by the 68LC040 Emulator, although all of the bits in the Cache Control Register (CACR) and Cache Address Register (CAAR) related to the instruction cache are supported. In general, of course, your code should not address the cache registers directly.
Because both emulated code and data reside in the PowerPC data cache, the performance benefits associated with caching are still present. Indeed, the caching scheme used transparently by the 68LC040 Emulator results in a higher level of software compatibility than is found on actual 680x0 microprocessors. Some older versions of software that
are incompatible with the 68040 cache mechanism can run without problem under
the emulator.
Requests to invalidate the 68040 instruction cache are ignored by the 68LC040 Emulator. However, you should continue to issue those calls in order to remain compatible with 680x0-based Macintosh computers. Moreover, all cache flushing required for PowerPC code fragments is performed automatically by the Code Fragment Manager.
Note
For details on invalidating the 680x0 instruction cache, see the chapter “Memory Management Utilities” in Inside Macintosh: Memory.u
It is possible, although unlikely, that an application depends on the ability of the 68040 instruction cache to retain a stale copy of instructions after the RAM copy of them has been changed. Such applications do not work correctly with 68000-based Macintosh computers (for example, the Macintosh Plus, SE, Classic®, or PowerBook 100) and any 68040-based computers (for example, the Macintosh Quadra 950) when the Cache CDEV is used to disable caching. As a result, this nonemulated behavior should not present any new compatibility problems.
Address Error Exceptions
To improve the performance of branch instructions, the 68LC040 Emulator is not completely compatible with an actual 68040 microprocessor when detecting and reporting address error exceptions. A 680x0 microprocessor checks for address errors before completing the execution of a branch instruction; if it finds an address error, the microprocessor reports (in an address error exception frame that it creates on the stack) the PC at the beginning of the branch instruction. By contrast, the 68LC040 Emulator checks for address errors after executing a branch instruction; as a result, it reports the odd branch address as the PC in the exception frame. Because the PC of the instruction that caused the branch is not reported, you might find it more difficult to debug an application that commits address errors. You might also have compatibility problems if you install an address error exception handler.
Bus Error Exceptions
The 68LC040 Emulator handles bus error exceptions slightly differently than does a real 680x0 microprocessor. If you install a bus error handler, you might need to be aware of these differences. You also need to be aware of these differences when debugging your software, because most debuggers need to handle bus error exceptions.
The 68LC040 Emulator creates format $B exception frames when generating and handling bus errors. However, several fields within the exception frame are documented by Motorola as internal fields, and the contents of those fields are very likely to differ between the 68LC040 Emulator exception stack frame and the exception stack frame created by a 680x0 microprocessor. You should not rely on these reserved fields. To avoid any possible confusion that the internal state information in the emulated exception frame is compatible with the internal state information created by the 680x0 micro-
processors, the exception frame created by the emulator intentionally uses a value in the Version Number field of the exception frame that is different from the value put there by any 680x0 microprocessor.
In addition, there are several documented fields of the bus error exception frame that have slightly different values in the emulator than on a 680x0-based Macintosh computer. As long as bus error exception handlers do not modify these fields, it is still possible to use the RTE instruction to continue execution of the instruction that caused the exception. In particular, the PC field of the exception frame might not point to the exact beginning of the instruction that generated the exception. Instead, it might point to some location near the beginning of that instruction. Also, the Stage B address field and the Stage B and Stage C instruction pipe fields might not contain valid information.
Finally, the Special Status Word (SSW) differs under the 68LC040 Emulator. The 68LC040 Emulator does not distinguish between instruction space and data space accesses; instead, it converts instruction fetches to data space reads. As a result, the FC2–FC0 field always indicates either a supervisor or a user data space reference. In addition, the emulator never sets the FC, FB, or RM bits, and it ignores the RC and RB bits. The DF bit is fully supported, however, allowing both program completion of bus cycles and rerunning of bus cycles with the RTE instruction. The 68LC040 Emulator also puts valid values in the RM and SIZ bits.
Memory-Mapped I/O Locations
In general, most applications do not directly access memory-mapped I/O locations. Instead, they call device drivers or other system software routines to perform the requested I/O operations. For code (such as a device driver) that does directly access memory-mapped I/O locations, there are a number of compatibility issues. In some cases, the 680x0 emulation environment might not perform some write operations that a real 680x0 performs:
n The BSET and BCLR instructions might not write back an operand if none of the bits were changed as a result of the operation.
n Some memory-to-memory MOVE instructions might not write to memory if the source and destination addresses are the same.
You might need to modify your application to use different sequences of instructions to perform the operations if an I/O device was expecting these write bus cycles.
The TAS, CAS, and CAS2 instructions in the 68040 instruction set perform indivisible read, modify, and write memory operations. The 68040 bus architecture provides a special locked bus cycle for a read-and-write operation without allowing any other devices to request the bus between them. These indivisible bus cycles cannot be emulated. As a result, an alternate bus master type of I/O device might be allowed to modify a memory location between the read and the write operations.
The 68020 and 68030 bus interface supports a feature called dynamic bus sizing that allows 8- or 16-bit-wide I/O devices to work with the 32-bit-wide data bus. If the processor has a memory request for a data width that was larger than the data width of the device connected to the bus, the memory interface breaks the request into multiple requests that are the width of the device. For example, if a 32-bit read request is made to an 8-bit device, the memory interface actually performs four separate 8-bit reads to assemble the 32-bit data. This feature cannot be emulated. Any application or other software that depends upon this feature must to be modified to use separate instructions to access and assemble each piece of data.
The 68020 and 68030 bus interface also supports a feature called byte smearing that allows 8- or 16-bit data to be duplicated on a write operation across all 32 bits of the
data bus. The 68040 processor does not support this feature. This feature cannot be emulated, but solutions that were used for the 68040 should be compatible with the 68LC040 Emulator.
The 68020, 68030, and 68040 microprocessors define the NOP instruction as having the effect of synchronizing the pipeline and waiting for all prior bus operations to complete. The 68020 and 68030 have a very small pipeline, and bus operations normally finish
soon after they are issued. However, the 68040 and the PowerPC architecture let memory operations be queued and issued out of order. Because of this, the NOP instruction
might be needed to ensure that accesses to memory-mapped I/O devices occur in the proper order. The 68LC040 Emulator supports the features of the NOP instruction.
Any application that includes NOP instructions should be compatible with all Macintosh computers.
If an I/O device causes a bus timeout that results in a bus error exception, it might not
be possible for the PowerPC microprocessor—and therefore the 68LC040 Emulator—
to determine the memory address that was accessed. If all locations within a 4 KB
I/O page consistently time out, this problem might not occur, but if accesses to some locations within a page sometimes succeed, it is possible for this situation to occur.
A bus error exception is generated in that case, but the Data Fault Address field in
the exception frame will not be accurate and the DF bit in the SSW will not be set.
Mixed Mode
An instruction set architecture is the set of instructions recognized by a particular processor or family of processors. The Mixed Mode Manager is the part of the Macintosh system software that manages mode switches between code in different instruction set architectures, switching the execution context between the CPU’s native PowerPC context and the 68LC040 Emulator. The 68LC040 Emulator is responsible for handling all code in the 680x0 instruction set. This includes existing 680x0 applications, device drivers, system extensions, and even parts of the system software itself that have not yet been rewritten to use the PowerPC instruction set.
Mode switches are required not only when the user switches from an emulated to a native application (or vice versa), but also when any application calls a system software routine or any other code that exists in a different instruction set. For example, the Memory Manager has been reimplemented in the first version of system software for PowerPC processor-based Macintosh computers as native PowerPC code. When an existing 680x0 application running under the 68LC040 Emulator calls a Memory Manager routine such as NewHandle, a mode switch is required to move out of the emulator and into the native PowerPC environment. Then, once the Memory Manager routine completes, another mode switch is required to return to the 68LC040 Emulator and to allow the 680x0 application to continue executing.
Similarly, PowerPC applications cause mode switches whenever they invoke routines that exist only as 680x0 code. For example, if a PowerPC application calls a part of
the Macintosh Toolbox or Operating System that has not been ported native, a mode
switch is required to move from the native environment to the environment of the 68LC040 Emulator.
The Mixed Mode Manager exists solely to manage these kinds of mode switches. It makes it possible for the execution environment of PowerPC processor-based Macintosh computers to accommodate a mixture of 680x0 applications, PowerPC applications, 680x0 system software, PowerPC system software, 680x0 executable resources, PowerPC executable resources, 680x0 device drivers, PowerPC device drivers, and so forth. The 68LC040 Emulator and the Mixed Mode Manager together allow both 680x0 code and PowerPC code to execute on the PowerPC microprocessor.
The Mixed Mode Manager is designed to hide, as much as possible, the hybrid nature of the mixed environment supported on PowerPC processor-based Macintosh computers. Occasionally, however, some executable code needs to interact directly with the Mixed Mode Manager to ensure that a mode switch occurs at the correct time. Because the 68LC040 Emulator is designed to allow existing 680x0 applications and system software to execute without modification, it’s always the responsibility of native applications
and system software to implement any changes necessary to interact with the Mixed Mode Manager.
This section describes the basic operation of the Mixed Mode Manager. It shows you how, if you’re writing a native application, you might need to modify your application to make it compatible with the mixed environment of the system software for PowerPC processor-based Macintosh computers. If you use fairly simple techniques for calling code external to your application and use only the standard types of callback routines, the information in this section might be sufficient for your needs. If not, see the chapter “Mixed Mode Manager” in this book for complete information about the Mixed
Mode Manager.
Cross-Mode Calls
The Mixed Mode Manager is intended to operate transparently to most applications and other kinds of software. This means, in particular, that most cross-mode calls (calls
to code in a different instruction set from the caller’s instruction set) are detected automatically by the Mixed Mode Manager and handled without explicit intervention by the calling software. For instance, when a 680x0 application calls a Memory Manager routine—which, as you have already learned, exists as PowerPC code in the system software for PowerPC processor-based Macintosh computers—the Trap Manager dispatches to the code pointed to by the appropriate entry in the trap dispatch table. For routines that are implemented as native code, the entry in the trap dispatch table is a pointer to a routine descriptor, a data structure used by the Mixed Mode Manager to encapsulate information about a routine. The first field in a routine descriptor is an executable 680x0 instruction that invokes the Mixed Mode Manager. The Mixed Mode Manager handles all the details of switching to the native mode, calling the native code, and then returning to the 68LC040 Emulator. The calling application is completely unaware that any mode switches have occurred.
The operation of the Mixed Mode Manager is also completely transparent when a PowerPC application calls a system software routine that exists as 680x0 code, although the exact details are slightly different. When a native application calls a system soft-
ware routine, the Operating System executes some glue code in an import library of executable code. The glue code inspects the trap dispatch table for the address of the called routine. If the called routine exists only as 680x0 code, the Mixed Mode Manager switches modes and calls the 680x0 routine. When the 680x0 code returns, the Mixed Mode Manager switches back to the native PowerPC environment and the execution of the PowerPC application continues.
Note
See “The PowerPC Native Environment” beginning on page 1-19
for information about the native execution environment, including import libraries.u
When writing PowerPC code, you need to explicitly intervene in the mode-switching process only when you execute code (or have code executed on your behalf) whose instruction set architecture might be different from that of the calling code. For example, whenever you pass the address of a callback routine to the Operating System or Toolbox, it’s possible that the instruction set architecture of the code whose address you are passing is different from the instruction set architecture of the routine you’re passing
it to. In such cases, you need to explicitly signal the type of code you’re passing and its calling conventions. Otherwise, the Mixed Mode Manager might not be called to make a required mode switch.
To see this a bit more clearly, suppose that you are writing a native PowerPC application that calls the Control Manager procedure TrackControl. TrackControl accepts as one of its parameters the address of an action procedure that is called repeatedly while the user holds down the mouse button in a control. TrackControl has no way of determining in advance the instruction set architecture of the code whose address you will pass it. Moreover, you have no way of determining in advance the instruction set architecture of the TrackControl procedure, so you cannot know whether your action procedure and the TrackControl procedure are of the same instruction set architecture. As a result, you must explicitly indicate the instruction set architecture of any callback routines whose addresses you pass to the system software.
Routine Descriptors
You indicate the instruction set architecture of a particular routine by creating a routine descriptor for that routine. Here is the structure of a routine descriptor.
struct RoutineDescriptor {
unsigned short goMixedModeTrap; /*mixed-mode A-trap*/
As you can see, the first field of a routine descriptor is an executable 680x0 instruction that invokes the Mixed Mode Manager. When the Mixed Mode Manager is called, it inspects the remaining fields of the routine descriptor—in particular the routineRecords field—to determine whether a mode switch is required. The routineRecords field is an array of routine records, each element of which describes a single routine. In the simplest case, the array of routine records contains a single element. Here is the structure of a routine record.
struct RoutineRecord {
ProcInfoType procInfo; /*calling conventions*/
unsigned char reserved1; /*reserved*/
ISAType ISA; /*instruction set architecture*/
RoutineFlagsType routineFlags; /*flags for each routine*/
The most important fields in a routine record are the procInfo field and the ISA field. The ISA field encodes the instruction set architecture of the routine being described. It must always contain one of these two constants:
enum {
kM68kISA = (ISAType)0, /*MC680x0 architecture*/
kPowerPCISA = (ISAType)1 /*PowerPC architecture*/
};
The procInfo field contains the routine’s procedure information, which encodes
the routine’s calling conventions and information about the number and location of
the routine’s parameters. For the standard kinds of callback procedures and other
types of “detached” code, the universal interface files include definitions of procedure information. For example, the C language interface file Controls.h includes
This procedure information specification indicates that a control action procedure follows standard Pascal calling conventions and takes two stack-based parameters,
a control handle and a part code; the action procedure returns no result. Similarly, the
file Controls.h defines the procedure information for a control definition function
Here, MyAction is the address of your control action procedure and GetCurrentISA
is a C language macro that returns the current instruction set architecture. When executed in the PowerPC environment, the NewRoutineDescriptor function creates
a routine descriptor in your application heap and returns the address of that routine descriptor. When executed in the 680x0 environment, the NewRoutineDescriptor function simply returns its first parameter. Notice that the result returned by
the NewRoutineDescriptor function is of type UniversalProcPtr. A universal procedure pointer is defined to be either a 680x0 procedure pointer or a pointer to a routine descriptor, essentially as follows:
Once you’ve executed the code in Listing 1-1 (probably at application launch time), you can later call TrackControl like this:
TrackControl(myControl, myPoint, myActionProc);
If your application is a PowerPC application, the value passed in the gActionProc parameter is not the address of your action procedure itself, but the address of the routine descriptor created in Listing 1-1. When a 680x0 version of TrackControl executes your action procedure, it begins by executing the instruction contained in the first field of the routine descriptor. That instruction invokes the Mixed Mode Manager, which inspects the instruction set architecture of the action routine (contained in the ISA field of the routine record contained in the routine descriptor). If that instruction set architecture differs from the instruction set architecture of the TrackControl routine, the Mixed Mode Manager causes a mode switch. Otherwise, if the two instruction set architectures are identical, the Mixed Mode Manager simply executes the action procedure without switching modes.
In short, you solve the general problem of indicating a routine’s instruction set archi-
tecture by creating routine descriptors and by using the addresses of those routine descriptors where you would have used procedure pointers in the 680x0 programming environment. You have to do this, however, only when you need to pass the address of a routine to some external piece of code (such as the Toolbox or Operating System or some other application) that might be in a different instruction set architecture from that of the routine. There are quite a number of cases in which you pass procedure pointers to the system software and which therefore require you to use the techniques illustrated above for Control Manager action procedures. Some of the typical routines you need to create routine descriptors for include
n grow-zone functions
n control action procedures
n event filter functions
n VBL tasks
n Time Manager tasks
n trap patches
n completion routines
The interface files for the PowerPC system software have been revised to change
all references to parameters or fields of type ProcPtr to references of type UniversalProcPtr. In addition, these new universal interface files contain procedure information definitions for all the standard kinds of callback routines. Moreover, the universal interface files define new routines that you can use in place of the more general code shown in Listing 1-1 on page 1-17. For example, the interface file Controls.h contains the definition shown in Listing 1-2 for the NewControlActionProc function.
Listing 1-2 The definition of the NewControlActionProc routine
In general, you should use the specific routines defined throughout the universal header files instead of the general technique illustrated in Listing 1-1.
IMPORTANT
You do not need to create routine descriptors for routines that are called only by your application. More generally, if you know for certain that a routine is always called by code of the same instruction set architecture, you can and should continue to use procedure pointers instead of universal procedure pointers. If, however, the address of one of your application’s routines might be passed to a Toolbox or Operating System routine, you should make sure to use a routine descriptor.s
Memory Considerations
The technique described in the previous section for using routine descriptors is by far the simplest and easiest to implement: any routine descriptors needed by an application are allocated in the application heap at application launch time. The descriptors remain allocated until the application terminates, at which time the entire application heap is reclaimed by the Process Manager. As a result, you don’t have to dispose of any routine descriptors created in this way.
If, in some case, you know that you won’t be needing a routine descriptor any more during the execution of your application, you can explicitly dispose of it by calling
the DisposeRoutineDescriptor function. This is most useful when you allocate a routine descriptor for temporary use only. For example, you might call some code that uses a callback procedure only very infrequently. In that case you can allocate the routine descriptor when the code is called and then release it when the code is done.
Finally, you can create a routine descriptor on the stack if you intend to use it only within a single procedure. The Mixed Mode Manager interface file MixedMode.h defines the C language macro BUILD_ROUTINE_DESCRIPTOR that you can use for this purpose, as well as for initializing static routine descriptors. For details, see “Using Static Routine Descriptors” on page 2-22 in the chapter “Mixed Mode Manager” in this book.
The PowerPC Native Environment
A run-time environment is a set of conventions that determine how code is loaded into memory, where data is stored and how it is addressed, and how functions call other functions and system software routines. The run-time environment available on a specific Macintosh computer is determined jointly by the Macintosh system software (which manages the loading and scheduling of executable code) and your software development system (which generates code to conform to the documented run-time conventions).
The run-time environment for native PowerPC code is significantly different from the run-time environment for 680x0 code with which you are probably already familiar.
In general, however, the PowerPC run-time environment is both simpler and more powerful than the 680x0 run-time environment. This increased simplicity and power
are due primarily to the use of fragments as the standard way of organizing executable code and data in memory. In the native PowerPC run-time environment, all discrete collections of executable code—including applications, code resources, extensions, and even the system software itself—are organized as fragments when loaded into memory. Accordingly, all executable code shares the benefits that derive from the organization of fragments, including
n a uniform set of calling conventions
n the ability to store code called by many applications or other software in
import libraries
n a simplified means of addressing global data
n the ability to execute special initialization and termination routines when the fragment is loaded into and unloaded from memory
This section describes the run-time environment for applications and other software executing on PowerPC processor-based Macintosh computers. It describes in detail
n the structure of fragments
n how to address global code and data
n subroutine invocation
n PowerPC stack frames
n import libraries
n the organization of memory
IMPORTANT
Keep in mind that the run-time environment defined by the use of fragments might in the future be available on 680x0-based Macintosh computers (and not solely on PowerPC processor-based Macintosh computers). The new run-time environment based on fragments is intended to be as processor independent as possible.s
Fragments
In the run-time environment introduced in the first version of the system software for PowerPC processor-based Macintosh computers, the basic unit of executable code and its associated data is a fragment. All fragments share a number of fundamental properties, such as their basic structure and their method of accessing code or data contained in themselves or in other fragments. There are, however, different uses for fragments, just as there are different uses for executable code in the 680x0 environment. Fragments can be loosely differentiated into three categories, based on how they
are used.
n An application is a fragment that can be launched by the user from the Finder (which calls the Process Manager to do the actual launching), typically to process documents or other collections of information. An application almost always has a user interface and uses standard event-driven programming techniques to control its execution.
n An import library is a fragment that contains code and data accessed by some other fragment or fragments. The Macintosh system software, for instance, is an import library that contains the code (and data) implementing the Macintosh Toolbox and Operating System routines. When you link an import library with your application, the import library’s code is not copied into your application. Instead, your application contains symbols known as imports that refer to some code or data in the import library. When your application is launched, the system software automatically resolves any imports your application contains and creates a connection to the appropriate import libraries.
n An extension is a fragment that extends the capabilities of some other fragment. For example, your application might use external code modules like menu definition functions, control definition functions, or data-conversion filters. Unlike import libraries, extensions must be explicitly connected to your application during its execution. There are two types of extensions: application extensions and system extensions. An application extension is an extension that is used by a single application. A system extension is an extension that is used by the Operating System or by multiple applications; it is usually installed at system startup time from a resource of type 'INIT', 'DRVR', or 'CDEV'.
Import libraries and system extensions are sometimes called shared libraries, because the code and data they contain can be shared by multiple clients. Import libraries and system extensions are also called dynamically linked libraries, because the link between your application and the external code or data it references occurs dynamically at application launch time.
The physical storage for a fragment is a container, which can be any kind of object accessible by the Operating System. The system software import library, for example, is stored in the ROM of a Macintosh computer. Other import libraries are typically stored in files of type 'shlb'. The fragment containing an application’s executable code is stored in the application’s data fork, which is a file of type 'APPL'. An extension can
be stored in a data file or in a resource in some file’s resource fork.
IMPORTANT
In general, it’s best to put an application extension into the data fork of some file (possibly even the application’s data fork itself), not into a resource. There is, however, one notable exception to this rule, namely when the extension is PowerPC code that is intended to operate in the same way as a 680x0 stand-alone code module. See “Executable Resources” on page 1-34 for more information.s
Before the code or data in a fragment can be used, it must be loaded into memory from its container and prepared for execution. This process is usually handled automatically by the Code Fragment Manager, the part of the Macintosh Operating System responsible for loading and preparing fragments. Fragment preparation consists mainly in resolving any imports in the fragment; the Code Fragment Manager searches for another fragment (an import library) that exports the symbols imported by the fragment being loaded. Of course, the import library containing the code or data imported by the first fragment might itself contain imported symbols from yet a third fragment. If so, the Code Fragment Manager needs to load and prepare the third fragment, then the second fragment, and finally the first fragment.
IMPORTANT
In general, the Code Fragment Manager is called by the Operating System in response to a request to load some specific fragment (for example, when the user launches an application). The import libraries used by that fragment are loaded automatically, if the Code Fragment Manager can find them. The Code Fragment Manager usually operates completely transparently, just like the 680x0-based Segment Manager. You need to use the Code Fragment Manager only if your application uses custom application extensions. See the beginning of the chapter “Code Fragment Manager” in this book for details.s
To load fragments into memory from the containers they are stored in, the Code Fragment Manager uses the Code Fragment Loader, a set of low-level services called mainly by the Code Fragment Manager. The Code Fragment Loader is responsible for knowing about container formats, such as PEF and XCOFF. Unless you need to design a new container format, you do not need to use the Code Fragment Loader. Currently, however, the application programming interface to the Code Fragment Loader is private.
The following sections describe the organization and operation of fragments in
greater detail.
The Structure of Fragments
Once a fragment has been loaded into memory and prepared for execution, the code and data it contains are available to itself and to any fragments that import parts of that code and data. The code and data of a particular fragment are loaded into separate sections
or regions of memory. In general, the code and data sections of a loaded fragment are
not contiguous with one another in memory. Instead, the data section of a fragment is loaded either into your application’s heap or into the system heap. The code section of a fragment is usually loaded elsewhere in memory. (See “File Mapping” beginning on page 1-53 for details on the location of the code sections of a fragment.) Regardless of where it is loaded, there is no segmentation within a code section of a fragment.
Because every fragment contains both code and data sections, it follows that any code executing in a fragment-based run-time environment—not just application code—can have global variables. (In the 680x0 run-time environment, it’s difficult for some kinds of code to have global variables.) In addition, there is no practical limit on the size of a fragment’s data section. By contrast, the total size of an application’s global variables
in the 680x0 environment is 32 KB, unless your development system provides special capabilities to exceed that limit.
Fragments created by the currently available linkers contain one section of code and one section of static data (although it’s theoretically possible to have more than one of each type of section). A fragment’s code section must contain pure executable code, that is, code that is independent of the location in memory where it is loaded. Pure code can be loaded anywhere in memory. As a result, it cannot contain any absolute branches. In addition, any references to the fragment’s data must be position-independent: there can be no absolute data addresses in the code. Because the code contained in a fragment’s code section must be pure and position-independent, and because a code section is always read-only, a fragment can be put into ROM or paged directly from an application file. In addition, it’s much easier to share pure code than it is to share impure code. This makes it very easy to implement import libraries as fragments.
A fragment’s data section contains the static data defined by the fragment. An applica-
tion’s data section is typically loaded into the application’s heap. An import library’s data section can be loaded into the system heap or into the heap of any application that uses the import library. Indeed, it’s possible for an import library’s data section to be loaded into memory at multiple locations, thereby creating more than one copy of the data. This is especially useful for providing different applications with their own copy of a library’s data. See “Import Libraries” beginning on page 1-50 for more details on this.
Even though a fragment’s code and data sections can be loaded anywhere in memory, those sections cannot be moved within memory once they’ve been loaded. Part of the process of loading a fragment into memory is to resolve any dependencies it might have upon other fragments. This preparation involves inserting into part of the fragment’s data section a number of pointers to data and code imported by the fragment from
other fragments, as described in the following section. To avoid having to perform
this fragment preparation more than once, the Operating System requires that a loaded fragment remain stationary in memory for as long as it is loaded.
Note
In the 680x0 environment, an application’s code can be unloaded (by the Memory Manager) and later reloaded into a different place in memory. This difference in run-time behavior leads to some important restrictions on stand-alone PowerPC code resources (called accelerated resources) that mimic the behavior of existing kinds of 680x0 code resources. See “Executable Resources” beginning on page 1-34 for details. u
Imports and Exports
As you’ve seen, a fragment (for example, an application) can access the code and data contained in some other fragment (typically an import library) by importing that code and data. Conversely, an import library can export code and data for use by other fragments (applications, extensions, or even other import libraries). It’s the responsibility of the linker to resolve any imports in your application (or other code fragment) to exports in some import library. The linker generates symbols that contain the name of the exporting library and the name of the exported symbol and inserts those symbols into your linked application.
Figure 1-2 illustrates how the linker resolves imports in an application. The SurfWriter object module contains a number of unresolved symbols. Some of the symbols reference code that is part of the system software contained in the InterfaceLib import library. Other unresolved symbols reference code in the SurfTool import library. The linker resolves those symbols and creates the SurfWriter application, which contains the names of the appropriate import library and function.
Figure 1-2 Creating imports in a fragment
When your application is launched, the Code Fragment Manager searches for the linker-generated import symbols and replaces them with the addresses of the imported code or data. To do this successfully, the Code Fragment Manager needs to find the appropriate import library and load it into memory if it isn’t already in memory. Then, it needs to bind the imported symbols in your application to the actual addresses, in the import library, of the imported code or data. Once the loading and binding of import libraries are complete, your application can execute.
Note
When binding imported symbols to external code and data, the Code Fragment Manager ensures that the version of the import library
used at link time to resolve external symbols is compatible with the version used at fragment loading time. See the chapter “Code Fragment Manager” in this book for a description of this version-checking capability. In general, this all happens transparently to your application or other code.u
It’s possible to designate some of the imports in your application (or other software) as soft. A soft import is an imported symbol whose corresponding code or data might not be available in any import library on the host machine and which is therefore undefined at run time. For example, a particular system software component such as QuickTime might not be available on all Macintosh computers. As a result, if you call QuickTime routines, you should mark all those imports as soft. When the Code Fragment Manager loads and prepares your application, it resolves the soft imports if the QuickTime code and data are available. If the QuickTime code and data aren’t available, the Code Fragment Manager inserts an invalid address (namely, kUnresolvedSymbolAddress) into your fragment’s table of contents entry for any QuickTime routines or data items.
sWARNING
You should always check to see that any imports declared as soft by your software were successfully resolved at load time. Trying to access code or data referenced by an unresolved soft import will cause your software to crash.s
For most system software services, you can use the Gestalt function to determine if the necessary code or data is available in the current operating environment. Note that this is not a new requirement and should not cause you to change your existing source
code; existing 680x0 software should also call Gestalt to ensure that needed system software services are available. When no Gestalt selector exists to test for the existence of a particular routine or data item, you can check for unresolved soft imports by comparing the address of the import to kUnresolvedSymbolAddress. Listing 1-4 illustrates this technique.
Listing 1-4 Testing for unresolved soft imports
extern int printf (char *, ...);
...
if (printf == kUnresolvedSymbolAddress)
DebugStr("\printf is not available.");
else
printf("Hello, world!\n");
See the description of the MakePEF tool in the book Building Programs for Macintosh With PowerPC for exact details on how to specify imports as soft.
The Table of Contents
The imported symbols in a fragment are contained in a special area in the fragment’s data section known as the table of contents (TOC). Prior to preparation by the Code Fragment Manager, a table of contents contains unresolved references to code and data in some other fragment. After preparation, the table of contents contains a pointer to each routine or data item that is imported from some other fragment. This provides a means of global addressing whereby a fragment can locate the code or data it has imported from other fragments.
Note
As you can see, the phrase “table of contents” is a slight misnomer, because a fragment’s table of contents does not supply a list of the addresses of routines or data in the fragment itself. Rather, a fragment’s table of contents consists (in part) of the addresses of code and data that the fragment imports, which reside in some other fragment. The table of contents is more akin to a personal address book. A fragment’s table of contents is private to the fragment itself and exists solely to provide external linkage for the code in the fragment.u
A fragment’s table of contents also contains pointers to the fragment’s own static data. Because the code and data sections of a fragment are usually loaded into different locations in memory, and because they must both be position-independent, the code section needs a method of finding its own data, such as data addressed by global variables. Global variables are addressed through the fragment’s table of contents. Within the compiled code of your application, references to global variables appear as indirect references via offsets into the table of contents.
Of course, for this scheme to work, the code section of a fragment needs to know where in memory its TOC begins. The address of the TOC cannot be compiled into the fragment; instead, the address of the TOC of the currently executing fragment is maintained in a register on the microprocessor. Currently, the general-purpose register GPR2 is dedicated to serve as the Table of Contents Register (RTOC). It contains the address in memory of the beginning of the TOC of the currently executing fragment.
It’s easy to see how a code fragment can find its own global data. It simply adds the compiled-in offset of a global variable within the TOC to the address of the TOC contained in the RTOC. The result is the address of a pointer to the desired data.
It’s slightly more complicated to see how a code fragment can execute an external piece of code. As it does with global data, the linker accesses external code via an offset into the TOC. The corresponding address in the TOC, however, is not the address of the piece of external code itself. Instead, the TOC of the calling fragment contains the address—in the static data section of the called fragment—of a transition vector, a data structure that contains two pointers: the address of the routine being called and the address of the called fragment’s TOC. The basic structure of a transition vector is shown in Figure 1-3.
Figure 1-3 A transition vector
Note
Strictly speaking, a transition vector can contain any number of pointers, as long as there are at least two. The first pointer is always the address of the routine being called, and the second pointer is always a value to be loaded into GPR2 prior to the execution of that routine. The second pointer in a transition vector can serve any purpose appropriate to the called routine. In the PowerPC environment for Macintosh computers, the second pointer is almost always the TOC address of the fragment containing the called routine. However, the callee is free to use the second pointer in other ways, if this is deemed useful. Your development system’s compiler ultimately determines the size and contents of a transition vector.u
A TOC entry for an external routine points to a transition vector largely so that the calling routine can set up an RTOC with the called fragment’s TOC value. Then, when the called routine exits, the caller restores the RTOC to its original value, pointing to the TOC of the calling fragment. This kind of function call is known as a cross-TOC call. During a cross-TOC call, GPR12 is assumed to point to the transition vector itself; this convention allows the called routine to access any additional fields in the transition vector beyond the first two.
To access data stored in another fragment, there is no need for the caller to install the TOC address of the other fragment in the RTOC. Instead, the TOC entry of the calling fragment contains a pointer to the external data, in exactly the same way that a TOC entry for global data in the same fragment contains a pointer to that data.
In short, a fragment’s table of contents contains
n one pointer for each imported routine called by the fragment; this pointer is the address of a transition vector in the data section of the import library.
n one pointer for each external data item used by the fragment; this pointer is the address of the data in the data section of the import library.
n one pointer for each global variable.
n one pointer for each pool of C static data internal to the fragment.
Note
Compilers and assembly-language programmers may place additional items in a fragment’s table of contents.u
The size of a fragment’s TOC is determined at the time your source code is compiled
and linked, but the actual values in the TOC cannot be determined until the fragment
is loaded and prepared for execution. When the Code Fragment Manager loads a fragment, it also loads any fragments that contain exports used by that fragment; at that
time, the addresses of those exports can be determined and placed into the original
fragment’s TOC.
The TOC provides the means whereby a routine in a given fragment can find its own static data and any external routines it calls. In providing access to a fragment’s own data, the TOC is analogous to the A5 world in applications created for the 680x0 run-
time environment. The TOC is more general than the A5 world, however, at least insofar as it allows stand-alone code to have global data; in the 680x0 environment, only applications have an A5 world and its resulting easy access to global data.
The Code Fragment Manager is responsible for dynamically resolving symbols in an unprepared TOC by binding them with their referents. This process involves finding unresolved imported symbols in the TOC, searching for the code or data they refer to, and replacing the symbols with the relevant addresses. This indirection through the TOC gives rise to a number of useful features.
n Routines external to a fragment can be specified by name, not by address. This allows routines to be grouped into import libraries.
n Data can be specified by name, not by address.
n Callback routines can be specified by name, not by address.
n Initialization and termination routines can be included in a fragment and are executed automatically by the Code Fragment Manager when the fragment is connected and disconnected, respectively.
n A fragment’s data can be either shared among multiple applications or instantiated separately for each application that uses the fragment. This feature is especially useful for fragments that are import libraries.
n The Code Fragment Manager can treat two import libraries as a single import library for the purposes of symbol resolution. This feature is especially useful for creating an update library—an import library that contains enhancements or bug fixes for an existing import library.
n A fragment’s code and data can be loaded anywhere in memory, because the address of a routine or a piece of data is always relative to the address contained in the RTOC.
Notice that TOC entries that point into another fragment always point into the data section of that fragment. This is a consequence of the fact that code is exported only through a transition vector in the fragment’s data section. Code symbols are never exported directly, but only via data symbols.
Because entries in a TOC are addressed using a register value plus an offset, and because offsets are signed 16-bit quantities, a table of contents can be at most 64 KB in size, with at most 16,384 entries. As already noted, current compilers and linkers create only one TOC per fragment. If you need to work with more than 16,384 pointers, you can create one or more import libraries, each of which can itself contain up to 16,384 pointers. As a practical matter, this is not a serious limitation.
Note
Future development tools might not create a TOC at all. The method
of collecting a fragment’s imported symbols and global data references into a table of contents is independent of the method of packaging code and data into a fragment. A fragment doesn’t need to have a table of contents, but all current development systems that create fragments do in fact create a single table of contents in each fragment.u
Although transition vectors are used primarily for cross-TOC calls (as described above), they are also used for pointer-based function calls. Whenever your application takes the address of a function (even one inside the same fragment), a transition vector is allocated to point to that function. Indeed, all function pointers in PowerPC code are actually pointers to transition vectors. If you are writing in assembly language, you need to be sure to export pointers to transition vectors instead of to actual code.
Special Routines
A fragment can define three special symbols that are separate from the list of symbols exported by the fragment. These symbols define an initialization routine, a termination routine, and a main routine (or block of data). These routines, if present, are called at specific times during the loading, unloading, or normal execution of a fragment. A fragment that is an application must define a main symbol that is the application’s entry point. Import libraries and extensions may or may not define any of these symbols.
A fragment’s initialization routine is called as part of the process of loading and preparing the fragment. You can use the initialization routine to perform any actions that should be performed before any of the fragment’s other code or static data is accessed. When a fragment’s initialization routine is executed, it is passed a pointer to a fragment initialization block, a data structure that contains information about the fragment. In particular, the initialization block contains information about the location of the fragment’s container. (For example, if an import library’s code fragment is contained in some file’s data fork, you can use that information to find the file’s resource fork.)
It’s important to know when the initialization routine for a fragment is executed. If the loading and preparation of a fragment cause a (currently unloaded) import library to be loaded in order to resolve imports in the first fragment, the initialization routine of the import library is executed before that of the first fragment. This is obviously what you would expect to happen, because the initialization routine of the first fragment might need to use code or data in the import library. In case there are two import libraries that depend upon each other, their developer may specify which should be initialized first.
A fragment’s termination routine is executed as part of the process of unloading a fragment. You can use the termination routine to undo the actions of the initialization routine or, more generally, to release any resources or memory allocated by the fragment.
Note
See “Fragment-Defined Routines” beginning on page 3-26 in the chapter “Code Fragment Manager” in this book for more information about a fragment’s initialization and termination routines.u
The use of a fragment’s main symbol depends upon the type of fragment containing it. For applications, the main symbol refers to the main routine, which is simply the usual entry point. The main routine typically performs any necessary application initialization not already performed by the initialization routine and then jumps into the application’s main event loop. For import libraries, the main symbol (if it exists) is ignored. For extensions having a single entry point, a main routine can be used instead of an exported symbol to avoid having to standardize on a particular name.
IMPORTANT
In fact, the main symbol exported by a fragment does not have to refer to a routine at all; it can refer instead to a block of data. You can use this fact to good effect with application extensions, where the block of data referenced by the main symbol can contain essential information about the extension. For instance, a loadable tool contained in a fragment might store its name, icon, and other information in that block. The Code Fragment Manager returns the address of the main symbol when you programmatically load and prepare a fragment.s
Fragment Storage
As you’ve learned, the physical storage for a fragment is a container. A container can be any logically contiguous piece of storage, such as the data fork of a file (or some portion thereof), the Macintosh ROM, or a resource. In the first version of the system software
for PowerPC processor-based Macintosh computers, the Code Fragment Loader can recognize two kinds of container formats, the Extended Common Object File Format (XCOFF) and the Preferred Executable Format (PEF).
XCOFF is a refinement of the Common Object File Format (COFF), the standard executable file format on many UNIX®-based computers. XCOFF is supported on Macintosh computers primarily because the early development tools produce executable code in the XCOFF format.
IMPORTANT
Not all object code in the XCOFF format will execute on Macintosh computers. Any XCOFF code that uses UNIX-style memory services or that otherwise depends on UNIX features will not execute correctly on Macintosh computers.s
PEF is an object file format defined by Apple Computer. A container in the PEF format is dramatically smaller than the corresponding container in the XCOFF format. This smaller size reduces both the disk space occupied by the container and the time needed to load the container’s code and data into memory. More importantly, PEF provides support for a fragment’s optional initialization and termination routines and for the version checking performed by the Code Fragment Manager when an import library is connected to a fragment.
As you know, the mixed environment provided by the first version of the system software for PowerPC processor-based Macintosh computers allows the user to run
both 680x0 and PowerPC applications. The Process Manager needs some method of determining, at the time the user launches an application, what kind of application it is. Because the mixed environment is intended to support existing 680x0 applications unmodified, the Process Manager assumes that an application is a 680x0 application, unless you specifically indicate otherwise. You do this by including, in the resource fork of your PowerPC application, a code fragment resource. This resource (of type 'cfrg' and ID 0) indicates the instruction set architecture of your application’s executable code, as well as the location of the code’s container. Typically, the code and data for a PowerPC application are contained in your application’s data fork, as shown in Figure 1-4.
Figure 1-4 The structure of a PowerPC application
If your application contains a code fragment resource, the Process Manager calls the Code Fragment Manager to load and prepare your application’s code and data. If, on the other hand, your application does not contain a code fragment resource, the Process Manager assumes that your application is a 680x0 application; in this case, the Process Manager calls the Segment Manager to load your application’s executable code from resources of type 'CODE' in your application’s resource fork, as illustrated in Figure 1-5.
Figure 1-5 The structure of a 680x0 application
Listing 1-5 shows the Rez input for a sample code fragment resource.
Listing 1-5 The Rez input for a sample 'cfrg' resource
#include "CodeFragmentTypes.r"
resource 'cfrg' (0) {
{
kPowerPC, /*instruction set architecture*/
kFullLib, /*no update level for apps*/
kNoVersionNum, /*no implementation version number*/
kNoVersionNum, /*no definition version number*/
kDefaultStackSize, /*use default stack size*/
kNoAppSubFolder, /*no library directory*/
kIsApp, /*fragment is an application*/
kOnDiskFlat, /*fragment is on disk*/
kZeroOffset, /*fragment starts at fork start*/
kWholeFork, /*fragment occupies entire fork*/
"SurfWriter" /*name of the application*/
}
};
The 'cfrg' resource specification in Listing 1-5 indicates, among other things, that the application consists of PowerPC code, that the code is contained in the application’s data fork, and that the code container occupies the entire data fork. It’s possible to have the container occupy only part of the data fork, if you need to put other information in
the data fork as well. (Some applications, for instance, put copyright or serial number information in their data fork.) You do this by specifying a nonzero offset for the begin-
ning of the code fragment. Alternatively, you can move the information previously contained in the data fork into one or more resources in your application’s resource fork, thereby reserving the entire data fork for the PowerPC code fragment.
Note
For information about the other fields in a code fragment resource,
see the chapter “Code Fragment Manager” in this book.u
This recommended placement of an application’s PowerPC code in the data fork makes it easy to create fat applications that contain both PowerPC and 680x0 executable code. A fat application contains 680x0 code in 'CODE' resources in the resource fork and PowerPC code in the data fork, as shown in Figure 1-6.
Figure 1-6 The structure of a fat application
The advantage of a fat application is that it can be executed on either 680x0-based or PowerPC processor-based Macintosh computers. The Process Manager on 680x0-based Macintosh computers knows nothing about 'cfrg' resources. As a result, it ignores the code contained in the data fork and uses the code contained in the application’s 'CODE' resources. The Process Manager on PowerPC processor-based Macintosh computers, however, reads the 'cfrg' resource and uses the code in the specified location (usually, the data fork); the 680x0 'CODE' resources in the resource fork are ignored.
Ideally, you should package your application as a fat application, to give your users maximum flexibility in how they manage their working environment. For example, a user might move a storage device (such as a hard disk) containing your application from a 680x0-based Macintosh computer to a PowerPC processor-based Macintosh computer. If your application is fat, it can be launched successfully in either environment.
For various reasons, however, you might decide not to package your application as a
fat application. If so, you should at the very least include an executable 680x0 'CODE' resource that displays an alert box informing the user that your application runs only on PowerPC processor-based Macintosh computers.
Note
Import libraries also need a code fragment resource, to indicate the location of the container and the appropriate version information.
See the chapter “Code Fragment Manager” in this book for information about creating a 'cfrg' resource for an import library.u
Executable Resources
The Code Fragment Manager is extremely flexible in where it allows fragments to be stored. As you’ve seen, an application’s executable code and global data are typically stored in a container in the application’s data fork. Import libraries supplied as part of the Macintosh system software are often stored in ROM, while import libraries created by third-party developers are usually stored in the data forks of files on disk. It’s also possible to use resources as containers for executable PowerPC code. This section describes how to work with executable resources in the PowerPC environment.
There are two kinds of executable resources you can create that contain PowerPC code: resources whose behavior is defined by the system software (or by some other software) and those whose behavior is defined by your application alone. For present purposes, these two kinds of resources are called accelerated and private resources, respectively.
Note
The terms accelerated and private are used here simply to help distinguish these two kinds of executable resources containing PowerPC code. They are not used elsewhere in this book or in Inside Macintosh.u
First, you can put an executable PowerPC code fragment into a resource to obtain
a PowerPC version of a 680x0 stand-alone code module. For example, you might recompile an existing menu definition procedure (which is stored in a resource of type 'MDEF') into PowerPC code. Because the Menu Manager code that calls your menu definition procedure might be 680x0 code, a mode switch to the PowerPC environment might be required before your definition procedure can be executed. As a result, you need to prepend a routine descriptor onto the beginning of the resource, as shown in Figure 1-7. These kinds of resources are called accelerated resources because they are faster implementations of existing kinds of resources. You can transparently replace 680x0 code resources by accelerated PowerPC code resources without having to change the software (for example, the application) that uses them.
Figure 1-7 The structure of an accelerated resource
Sometimes it’s useful to keep the executable code of a definition function in some location other than a resource. To do this, you need to create a stub definition resource that is of the type expected by the system software and that simply jumps to your code. For example, Listing 1-6 shows the Rez input for a stub list definition resource.
Listing 1-6 Rez input for a list definition procedure stub
data 'LDEF' (128, "MyCustomLDEF", preload, locked) {
/*need to fill in destination address before using this stub*/
Your application (or other software) is responsible for filling in the destination address before the list definition procedure is called by the List Manager. For 680x0 code, the destination address should be the address of the list definition procedure itself. For PowerPC code, the destination address should be a universal procedure pointer (that is, the address of a routine descriptor for the list definition procedure).
By contrast, you can create a resource containing executable PowerPC code solely for the purposes of your application (perhaps on analogy with the standard kinds of code-
bearing resources used by the system software). Because these kinds of executable resources do not conform to a calling interface defined by the system software (or by some other widely available software, such as HyperCard), they are called private resources. The code in private resources is called only by your application, not by any other external code. As a result, there is no need to put a routine descriptor onto the beginning of the executable code. Figure 1-8 shows the general structure of a private resource.
Figure 1-8 The structure of a private resource
It’s important to understand the distinction between accelerated and private resources, so that you know when to create them and how to load and execute the code they contain. An accelerated resource is any resource containing PowerPC code that has a single entry point at the top (the routine descriptor) and that models the traditional behavior of a 680x0 stand-alone code resource. There are many examples, including menu definition procedures (stored in resources of type 'MDEF'), control definition functions (stored in resources of type 'CDEF'), window definition functions (stored in resources of type 'WDEF'), list definition procedures (stored in resources of type 'LDEF'), HyperCard extensions (stored in resources of type 'XCMD'), and so forth. A private resource is any other kind of executable resource whose code is called directly by your application.
IMPORTANT
IMPORTANT
For several reasons, it’s generally best to avoid using private resources unless you absolutely must put some code into a resource. As you’ll see later (in “File Mapping” on page 1-53), the executable code of a private resource is loaded into your application’s heap and is not eligible for
file mapping. Whenever possible, you should put executable PowerPC code into your application’s data fork or create your own application-
specific files.s
In most cases, you don’t need to do anything special to get the system software to recognize your accelerated resource and to call it at the appropriate time. For
example, the Menu Manager automatically loads a custom menu definition procedure into memory when you call GetMenu for a menu whose 'MENU' resource specifies
that menu definition procedure. Similarly, HyperCard calls code like that shown in
Listing 1-7 to load a resource of type 'XCMD' into memory and execute the code
it contains.
Listing 1-7 Using an accelerated resource
Handle myHandle;
XCmdBlock myParamBlock;
myHandle = Get1NamedResource('XCMD', '\pMyXCMD');
HLock(myHandle);
/*Fill in the fields of myParamBlock here.*/
CallXCMD(&myParamBlock, myHandle);
HUnlock(myHandle);
The caller of an accelerated resource executes the code either by jumping to the code (if the caller is 680x0 code) or by calling the Mixed Mode Manager CallUniversalProc function (if the caller is PowerPC code). In either case, the Mixed Mode Manager calls the Code Fragment Manager to prepare the fragment, which is already loaded into memory. With accelerated resources, you don’t need to call the Code Fragment Manager yourself. In fact, you don’t need to do anything special at all for the system software
to recognize and use your accelerated resource, if you’ve built it correctly. This is
because the system software is designed to look for, load, and execute those resources
in the appropriate circumstances. In many cases, your application passes to the system software just a resource type and resource ID. The resource must begin with a routine descriptor, so that the dereferenced handle to the resource is a universal procedure pointer.
IMPORTANT
IMPORTANT
The MPW interface file MixedMode.r contains Rez templates that you can use to create the routine descriptor that appears at the beginning
of an accelerated resource. If you want to build the routine descriptor yourself or if you want to build a fat accelerated resource (which contains both PowerPC and 680x0 code), see the section “Executing Resource-Based Code” beginning on page 2-24 in the chapter “Mixed Mode Manager” in this book.s
The code shown in Listing 1-7—or similar code for any other accelerated resource—can be executed multiple times with no appreciable performance loss. If the code resource remains in memory, the only overhead incurred by Listing 1-7 is to lock the code, fill in the parameter block, jump to the code, and then unlock it. However, because of the way in which the system software manages your accelerated resources, there are several key restrictions on their operation:
n An accelerated resource cannot contain a termination routine, largely because the Operating System doesn’t know when the resource is no longer needed and hence when the resource can be unloaded. The Code Fragment Manager effectively forgets about the connection to your resource as soon as it has prepared the resource for execution.
n An accelerated resource must contain a main symbol, which must be a procedure. For example, in an accelerated 'MDEF' resource, the main procedure should be the menu definition procedure itself (which typically dispatches to other routines contained in the resource).
n You cannot call the Code Fragment Manager routine FindSymbol to get information about the exported symbols in an accelerated resource. More generally, you cannot call any Code Fragment Manager routine that requires a connection ID as a parameter. The connection ID is maintained internally by the Operating System and is not available to your application.
n The fragment’s data section is instantiated in place (that is, within the block of memory into which the resource itself is loaded). For in-place instantiation, you
need to build an accelerated resource using an option that specifies that the data section of the fragment not be compressed. See the documentation for your soft-
ware development system for instructions on doing this.
Note
If you use the MakePEF tool to help build an accelerated resource, you should specify the -b option to suppress data section compression.u
You might have noticed that the code shown in Listing 1-7 unlocks the 'XCMD' resource after executing it. By unlocking the resource, the caller is allowing it to be moved around in memory or purged from memory altogether. This behavior—which is perfectly acceptable in the 680x0 environment—contradicts the general rule that fragments are not allowed to move in memory after they’ve been loaded and prepared (see page 1-23). To allow accelerated PowerPC resources to be manipulated just like 680x0 code resources, the Mixed Mode Manager and the Code Fragment Manager cooperate to make sure that the code is ready to be executed when it is called. If the resource code hasn’t been moved since it was prepared for execution, then no further action is necessary. If, however, the code resource has moved or been reloaded elsewhere in memory, some of the global data in the resource might have become invalid. For example, a global pointer might become dangling if the code or data it points to has moved. To help avoid dangling pointers, the Code Fragment Manager updates any pointers in the fragment’s data section that are initialized at compile time and not modified at run time. However, the Code Fragment Manager cannot update all global data references in an accelerated resource that has moved in memory. There is, therefore, an important restriction on using global data in accelerated resources:
n An accelerated resource must not use global pointers (in C code, pointers declared as extern or static) that are either initialized at run time or contained in dynamically allocated data structures to point to code or data contained in the resource itself. An accelerated resource can use uninitialized global data to point to objects in the heap. In addition, an accelerated resource can use global pointers that are initialized at compile time to point to functions, other global data, and literal strings, but these pointers cannot be modified at run time.
Listing 1-8 shows some declarations that can be used in an accelerated resource, provided that the resource code does not change the values of the initialized variables.
Listing 1-8 Some acceptable global declarations in an accelerated resource
int a; /*uninitialized; not modified if resource moves*/
Ptr myPtr; /*uninitialized; not modified if resource moves; */
/* can be assigned at run time to point to heap object*/
Handle *h; /*uninitialized; not modified if resource moves; */
/* can be assigned at run time to point to heap object*/
int *b = &a; /*updated each time resource moves*/
char *myStr = "Hello, world!"; /*updated each time resource moves*/
extern int myProcA(), myProcB();
struct {
int (*one)();
int (*two)();
char *str;
} myRec = {myProcA, myProcB, "Hello again!"};
/*all three pointers are updated each time resource moves*/
Listing 1-9 shows some data declarations and code that will not work in an accelerated resource that is moved or purged.
Listing 1-9 Some unacceptable global declarations and code in an accelerated resource
int a;
int *b;
int *c = &a;
Ptr (*myPtr) (long) = NewPtr;
static Ptr MyNewPtr();
struct myHeapStruct {
int *b;
Ptr (myPtr) (long);
} *hs;
b = &a; /*b does not contain &a after resource is moved*/
c = NULL; /*c does not contain NULL after resource is moved*/
c = (int *) NewPtr(4); /*dangling pointer after resource is moved*/
myPtr = MyNewPtr; /*dangling pointer after resource is moved*/
hs = NewPtr(sizeof(myHeapStruct));
/*hs still points to nonrelocatable heap block after move*/
hs->b = &a; /*hs->b will not point to global a after move*/
hs->myPtr = MyNewPtr;
/*hs->myPtr will not point to MyNewPtr after move*/
Note that a code fragment stored as an accelerated resource can import both code and data from an import library. The code and data in the import library do not move in memory. As a result, you can sidestep the restrictions on global data in an accelerated resource by putting the global data used by the accelerated resource into an import library. The import library is unloaded only when your application terminates, not when the accelerated resource is purged.
To load and prepare a private resource, you need to call the Resource Manager, Memory Manager, and Code Fragment Manager explicitly, as shown in Listing 1-10.
None of the restrictions on accelerated resources listed above applies to your own private code-bearing resources. For instance, you do have access to the connection ID
to the resource-based fragment (as you can see in Listing 1-10), so you can call Code Fragment Manager routines like CloseConnection and FindSymbol. However, the overhead involved in loading the code fragment and later unloading it is nontrivial,
so you should avoid closing the connection to a private resource (that is, calling CloseConnection) until you’re done using it.
Because a private resource is just a fragment stored in a resource, it’s preferable to
avoid using private resources, whenever possible, by putting that code and data into some file. By doing this, you gain the benefits afforded by the system software to file-
based fragments (such as file mapping directly from the file’s data fork). You should use private executable resources only in cases where your code absolutely must be packaged in a resource.
Calling Conventions
The software development tools and the system software for PowerPC processor-based Macintosh computers dictate a set of calling conventions that are significantly different from those you might be used to in the 680x0 execution environment. The new calling conventions are designed to reduce the amount of time required to call another piece of code and to simplify the entire code-calling process. In the 680x0 environment, there are many ways for one routine to call another, depending on whether the called routine conforms to Pascal, C, Operating System, or other calling conventions. In the PowerPC environment, there is only one standard calling convention, having these features:
n Most parameters are passed in registers dedicated for that purpose. The large number of general-purpose and floating-point registers makes this goal quite easy to achieve. Parameters are passed on the stack only when they cannot be put into registers.
n The size of a stack frame is determined at compile time, not dynamically at run time.
n Stack frames are subject to a strict set of rules governing their structure. The new run-time architecture reserves specific areas of a stack frame for saved registers, local variables, parameters, and stack frame linkage information (such as the return address and the beginning of the previous stack frame).
The following sections describe these differences in greater detail. They begin by reviewing the procedure calling conventions that exist on 680x0-based Macintosh computers. Then they describe the calling conventions adopted for PowerPC processor-based Macintosh computers and show how those conventions affect the organization of the stack.
IMPORTANT
The information in the following sections is provided primarily for debugging purposes or for compiler writers and assembly-language programmers, who need to conform to the new calling conventions. Because generating code conforming to these conventions is handled automatically by your compiler, you might not need this information
for writing applications in a high-level language.s
The 680x0 Calling Conventions
To appreciate how different the PowerPC calling conventions are from the 680x0 calling conventions, it’s useful to review the model used on 680x0-based Macintosh computers. On 680x0-based computers, there is a conventional grow-down stack whose parts are delimited by two pointers: a stack pointer and a frame pointer. Figure 1-9 illustrates a typical 680x0 stack frame.
Figure 1-9 A 680x0 stack frame
Note
By convention, the stack grows from high memory addresses toward low memory addresses. The end of the stack that grows or shrinks is usually referred to as the “top” of the stack, even though it’s actually at the lower end of memory occupied by the stack.u
The stack pointer (SP) points to the top of the stack and defines its current downward limit. All operations that push data onto the stack or pop data off it do so by reading and then modifying the stack pointer. The Operating System uses the 680x0 register A7 as the stack pointer.
The frame pointer (FP) points to the base in memory of the current stack frame, the area of the stack used by a routine for its parameters, return address, local variables, and temporary storage. Because the Operating System maintains the frame pointer, it can easily find the beginning of the stack frame when it’s time to pop it off the stack. The Operating System uses the 680x0 register A6 as the frame pointer.
A routine’s parameters are always placed on the stack above the frame pointer, and its local variables are always placed below the frame pointer. The 680x0 hardware enforces 16-bit alignment for parameters on the stack. So, for example, if you push a single byte onto the stack, the stack pointer is decremented by 2 bytes rather than 1.
The order of the parameters on the stack differs according to the language type of the called routine. When you call a C routine on a 680x0-based Macintosh computer, the parameters are pushed onto the stack in order from right to left. This order is dictated by the fact that the C language allows routines with a variable number of parameters. The first parameter (which often indicates how many parameters are being passed) must always be pushed onto the stack last, so that it resides at a fixed offset from the frame pointer. Moreover, because only the caller knows how many parameters it pushed onto the stack, it is always the caller’s responsibility to pop the parameters off the stack. Finally, with C routines, a function result is returned in register D0 (or, for floating-point results, in register FPR0). However, structures and other large values are handled differently: the caller allocates space for the result and passes a pointer to that storage as the first (that is, leftmost) parameter.
The calling conventions for Pascal routines are different from those for C routines. For Pascal routines, the caller pushes space for the return result onto the stack before pushing the parameters. The caller pushes parameters onto the stack from left to right. Because Pascal does not allow routines with a variable number of parameters, the size of a stack frame can be determined at compile time. It is therefore the responsibility of the called routine to remove the parameters from the stack before returning.
Note
These differences between C and Pascal are due entirely to
historical factors, not to any requirements of the 680x0
environment. It would have been possible for Pascal routines
to follow the C calling conventions.u
There are still other calling conventions followed on 680x0-based Macintosh computers. Macintosh Toolbox managers generally follow Pascal conventions, although some of the most recent additions to the Toolbox follow C conventions. More importantly, the Macintosh Operating System typically ignores the stack altogether. Instead, Operating System calls generally pass parameters and return results in registers.
The PowerPC Calling Conventions
The native run-time environment on PowerPC processor-based Macintosh computers uses a set of uniform calling conventions:
n Parameters are processed from left to right and are placed into general-purpose registers GPR3 through GPR10 and (when necessary) floating-point registers FPR1 through FPR13.
n Function results are returned in GPR3, FPR1, or by passing a pointer to a structure as the implicit leftmost parameter (as in the 680x0 C implementation).
n Any parameters that do not fit into the designated registers are passed on the stack. In addition, enough space is allocated on the stack to hold all parameters, whether they are passed in registers or not.
Like the 680x0 run-time environment, the PowerPC run-time environment uses a grow-
down stack that contains areas for a routine’s parameters, for linkage information, and for local variables. However, the organization of the stack in the PowerPC environment is significantly different from that in the 680x0 environment. The PowerPC run-time environment uses a single stack pointer and no frame pointer. To achieve this simplifica-
tion, the PowerPC stack has a much more rigidly defined structure than does the stack in the 680x0 environment. Figure 1-10 illustrates the general structure of the stack in the PowerPC environment.
Figure 1-10 The PowerPC stack
The caller’s stack frame includes a parameter area and some linkage information. The parameter area in each stack frame is used by the caller to hold the parameters of any routines the caller calls (not the parameters of the caller itself). Of course, a given routine might in turn call several other routines; if so, the parameter area in the caller’s stack frame is made large enough to accommodate the largest parameter list of all routines the caller calls. It is the caller’s responsibility to set up the parameter area before each call to some other routine, and the callee’s responsibility to access its parameters from that parameter area. See the following section, “Parameter Passing” on page 1-47, for details on the structure of a routine’s parameter area.
Once the caller has set up the parameters for a call to some other routine, it then stores its own RTOC value in its linkage area, an area of the caller’s stack frame that holds the saved stack pointer, Condition Register (CR), Link Register (LR), and RTOC values. It is necessary to save the caller’s RTOC value because the callee might reside in another fragment, a situation that would require that the callee’s RTOC value be installed in the RTOC. The caller always restores its RTOC value immediately upon return from the callee. The callee’s prolog writes the saved Condition Register and Link Register into the caller’s linkage area. The structure of a linkage area is illustrated in Figure 1-11.
IMPORTANT
The RTOC value is saved and restored only for two kinds of subroutine calls: cross-TOC calls and pointer-based calls. In all other cases, the RTOC field of the caller’s linkage area is ignored.s
Figure 1-11 The structure of a stack frame’s linkage area
Notice that the linkage area always appears at the “top” of the stack, adjacent to the stack pointer. This positioning is necessary to allow the caller to find and restore the values saved there, and to allow the callee to find the caller’s parameter area. One consequence of this requirement, however, is that a routine cannot push and pop arbitrary values on the stack after a stack frame is set up.
A PowerPC stack frame also includes space for the callee’s local variables. In general, the general-purpose registers GPR13 through GPR31 and the floating-point registers FPR14 through FPR31 are reserved for a routine’s local variables. If a particular routine has more local variables than fit entirely into the registers reserved for them, it uses addi-
tional space on the stack. The size of the area used for local variables is determined at compile time; once a stack frame is allocated, the area for local variables cannot grow
or shrink.
The callee is responsible for allocating its own stack frame, making sure to preserve 8-byte alignment on the stack. The callee allocates its stack frame by decrementing the stack pointer, then writes the previous stack pointer into its own linkage area and saves all nonvolatile general-purpose and floating-point registers into the saved registers area of its stack frame. All of these actions are performed by a standard piece of compiler-generated code called the prolog.
Note
Note
The order in which the callee’s prolog performs these actions is determined by convention, not by any requirements of the PowerPC run-time architecture. Also, the callee saves only those nonvolatile registers it uses; if the callee doesn’t change a particular nonvolatile register, it doesn’t bother to save and restore it.u
When the callee exits, its epilog code restores the nonvolatile registers that its prolog previously saved. The Link Register and Condition Register are restored from the linkage area in the caller’s stack frame. The nonvolatile general-purpose registers (namely, GPR13 through GPR31) and floating-point registers (namely, FPR14 through FPR31) are restored from the saved register area in the callee’s stack frame. The RTOC value of the caller is, however, restored by the caller immediately upon return from the called routine.
There is one special case in which a callee’s stack usage does not conform to the structure shown in Figure 1-10—namely, when the callee is a leaf procedure. A leaf procedure
is a procedure that calls no other procedures. Because it doesn’t call any procedures,
it doesn’t need to allocate a parameter area on the stack. If, in addition, a leaf procedure doesn’t need to use the stack for any local variables, it needs to save and restore only those nonvolatile registers that it uses for local parameters.
Leaf procedures, due to their limited stack requirements, can use a special area on the stack called the Red Zone. The Red Zone is the area just below the stack pointer, in the area where a new stack frame normally would be allocated (see Figure 1-12). Because by definition only one leaf procedure can be active at any time, there is no possibility of multiple leaf procedures competing for the same Red Zone space.
Figure 1-12 The Red Zone
It’s important to realize that a leaf procedure doesn’t actually allocate a stack frame for itself and that it doesn’t decrement the stack pointer. Instead, it stores its LR and CR values in the linkage area of the routine that calls it (if necessary) and stores the values
of any nonvolatile registers it uses in the Red Zone. As a result, the epilog of a leaf procedure doesn’t need to tear down a stack frame. Instead, the epilog needs at most to restore the calling routine’s LR and CR values. This allows leaf procedures to execute faster than they would if they had to set up and later tear down a complete stack frame.
Note
A leaf procedure uses the Red Zone in place of a stack frame only when your code is compiled with speed optimization enabled.u
Using the Red Zone in this way can, however, cause problems for native exception handlers, because an exception handler cannot know in advance if a leaf procedure is executing at the time the exception occurs (and hence cannot know if the Red Zone contains information that should be preserved). A native exception handler must therefore decrement the stack pointer by 224 bytes (the largest possible register save area) before using the stack, to skip over any Red Zone that might currently be in use.
Note
The value 224 is the space occupied by nineteen 32-bit general-purpose registers plus eighteen 64-bit floating-point registers, rounded up to the nearest 8-byte boundary. If a leaf procedure’s Red Zone usage would exceed 224 bytes, then the leaf procedure is forced to use a stack frame, like any other procedure.u
In general, you should use the new Exception Manager to install any native exception handlers your application or other software defines. The Exception Manager automati-
cally adjusts the stack pointer before calling your exception handler and then restores it after your handler exits. See the chapter “Exception Manager” in this book for complete details on writing and installing a native exception handler.
IMPORTANT
The calling conventions and stack usage described in this section are those of the PPCC compiler and the Macintosh Operating System. Other compilers may employ different calling conventions.s
Parameter Passing
In the PowerPC run-time environment, as you’ve already learned, parameters are usually passed from a caller to a callee in registers. The fact that there are many general-
purpose and floating-point registers dedicated for parameter passing makes it extremely likely that all of a subroutine’s parameters can be passed in registers. Passing parameters in registers reduces the number of memory accesses required (namely, to read the stack frame) and thereby increases the performance of your software.
Any parameters that cannot be passed in registers are instead passed in the parameter area of the caller’s stack frame. This section describes the way in which a caller prepares the registers and the parameter area for the callee.
IMPORTANT
You need the information in this section only for machine-level debugging purposes, to understand the contents of the general-purpose and floating-point registers and the structure of the parameter area in a caller’s stack frame.s
The compiler assigns parameters to registers and to the parameter area in the caller’s stack frame according to this algorithm:
n The parameters are arranged in order as if they were fields of a record.
n The leftmost parameter is the first field.
n Each field is aligned on a 32-bit word boundary.
n Integer parameters occupying less than 32 bits are extended to 32 bits.
n Some parameter values are passed in registers.
n The first 8 words are passed in GPR3 through GPR10.
n However, the first 13 floating-point parameters are passed in FPR1 through FPR13.
n Simple function results are returned in GPR3 or FPR1.
n Composite data (that is, custom data structures such as Pascal records or C structures) are passed intact, without expanding the fields to achieve word alignment. When composite data is returned, the caller leaves enough room to hold the result on the stack, puts the address of the result into GPR3, and starts the parameters in GPR4.
n Any parameters that do not fit into the available registers are passed in the parameter area of the caller’s stack frame.
The compiler generates a parameter area in the caller’s stack frame that is large enough to hold all parameters passed to the callee, regardless of how many of the parameters are actually passed in registers. There are several reasons for this scheme. First of all, it provides the callee with space to store a register-based parameter if it wants to use one of the parameter registers for some other purpose (for instance, to pass parameters to a subroutine). In addition, routines with variable-length parameter lists must access their parameters from RAM, not from registers. Finally, code that is built to allow debugging automatically writes parameters from the parameter registers into the parameter area in the stack frame; this allows you to see all the parameters by looking only at that parameter area.
Consider, for example, a function MyFunction with this declaration:
unsigned char c1, unsigned short s2, float f2, int i2);
Note
On the PowerPC processor, integers and long integers are both 32 bits long and short integers are 16 bits long. Variables of type float are
32 bits long; variables of type double are 64 bits long.u
To see how the parameters of MyFunction are arranged in the parameter area on the stack, first convert the parameter list into a structure, as follows:
struct params {
int pi1;
float pf1;
double pd1;
short ps1;
double pd2;
unsigned char pc1;
unsigned short ps2;
float pf2;
int pi2;
};
This structure serves as a template for constructing the parameter area on the stack. (Remember that, in actual practice, many of these variables are passed in registers; nonetheless, the compiler still allocates space for all of them on the stack, for the reasons just mentioned.)
The “top” position on the stack is for the field pi1 (the structure field corresponding to parameter i1). The floating-point field pf1 is assigned to the next word in the parameter area. The 64-bit double field pd1 is assigned to the next two words in the parameter area. Next, the short integer field ps1 is placed into the following 32-bit word; the original value of ps1 is in the lower half of the word, and the padding is in the upper half. The remaining fields of the param structure are assigned space on the stack in exactly the same way, with unsigned values being extended to fill each field to a 32-bit word. The final arrangement of the stack is illustrated in Figure 1-13. (Because the stack grows down, it looks as though the fields of the params structure are upside down.)
Figure 1-13 The organization of the parameter area on the stack
To see which parameters are passed in registers and which are passed on the stack, you need to map the stack, as illustrated in Figure 1-13, to the available general-purpose and floating-point registers. Registers GPR0 through GPR2, and register FPR0, are reserved for other uses. Therefore, the parameter i1 is passed in GPR3, the first available general-purpose register. The floating-point parameter f1 is passed in FPR1, the first available floating-point register.
Placing a floating-point parameter into a floating-point register also reserves one or two general-purpose registers, depending on whether the parameter is 32 or 64 bits long. This behavior is dictated in order to support the ability of a C function to call another function without knowing the number or types of the callee’s parameters—that is, without knowing the callee’s prototype. When no function prototype for the callee is available to the caller, the compiler cannot know whether to pass a given parameter
in the general-purpose (that is, fixed-point) registers or in the floating-point registers.
As a result, the compiler passes the parameter in both the floating-point and the general-
purpose registers.
Even when the caller knows the function prototype of the callee, it still reserves one or two general-purpose registers for each floating-point register it fills. The only difference between cases in which the prototype is available and cases in which the prototype isn’t available is that the floating-point parameters are copied into the general-purpose register(s) in the latter cases but not in the former.
The parameter d1 is placed into FPR2 and the corresponding general-purpose registers GPR5 and GPR6 are masked out. The parameter s1 is placed into the next available general-purpose register, GPR7. Parameter d2 is placed into FPR3, with GPR8 and GPR9 masked out. Parameter c1 is placed into GPR10, thereby exhausting all available general-
purpose registers. However, parameter f2 is passed in FPR4, which is still available. Notice that there are no general-purpose registers that can be masked out for FPR4; as a result, the parameter f2 is passed both in FPR4 and on the stack. Finally, parameters s2 and i2 must be passed on the stack, because there are no more general-purpose registers to hold them.
Note
It would have been possible to pass all the fixed-point values in registers if the floating-point parameters had been grouped at the end of the parameter list.u
There is a special case that applies to routines that take a variable number of parameters (for example, the C language function printf). The callee doesn’t know how many parameters are being passed to it on any given call. As a result, the callee saves registers GPR3 through GPR10 into the parameter area and then walks through the parameter area to access its parameters. This means that the parameter area must contain at least
8 words.
Import Libraries
You’ve already learned (in “Fragments” beginning on page 1-20) how a fragment can import code and data from some other fragment, which is always an import library. Because the code or data that your application references from an import library is not actually contained in your application—but is only linked to it dynamically at application launch time—the executable code of your application is generally much smaller than it otherwise would be. This is one of the main advantages of using import libraries.
Of course, there’s no particular advantage simply to moving code out of your application and into an import library, because the code in the import library, unless contained in ROM, must be loaded into RAM before it can be used. The real advantages accrue only when two or more applications use the same import library. The library’s code is loaded into RAM only once, and all those applications reference that single code base. If you are developing several PowerPC applications that have parts of their source code in common, you should consider packaging all the shared code into an import library.
Another important advantage of using import libraries is that it’s easy to update code contained in an import library. You can issue an updated version of your import library and have the changes propagate to all the applications that use that library. You don’t need to update each individual application that uses the import library.
You can use shared libraries in other useful ways. You can, for instance, create a shared library that holds optional or infrequently executed code. For example, if you’re writing a word-processing application, you might package its spell-checking module as a separate shared library. Because the Code Fragment Manager doesn’t load the library at application launch time, your application uses less RAM and launches more quickly. When the user wants to execute the spelling checker, your application must explicitly load and prepare the shared library by calling Code Fragment Manager routines.
You can also use shared libraries as a way to allow other developers to add capabilities, such as optional tools, to your application. If you document the format of the parameters passed to an external routine and any other data that you expect to find in an optional tool, other developers can create shared libraries that conform to those specifications.
As you know, the principal advantage of using import libraries is that the code in the import library is loaded only once in memory, whence it is addressed by all applications (or other fragments) that import that code. The handling of an import library’s data, however, is more complicated. The Code Fragment Manager supports two methods of allocating and using the static data (that is, global variables) in an import library:
n Global instantiation. The Code Fragment Manager allocates a single copy of the library’s global data, no matter how many clients use that data.
n Per-context instantiation. The Code Fragment Manager allocates one copy of the library’s global data for each separate application (and all other fragments in the application’s context) that uses that data. Each application can access only its own copy of the data. The Operating System automatically keeps track of which copy of the library’s global data is in use by which context. If a given application attempts to load the same import library more than once, it always accesses the same copy of the library’s global data.
The method of allocating and handling a library’s global data is determined at link time. The library developer can indicate either global or per-context data instantiation for each
separate data section in a library. The method selected by the library developer for a particular data section is recorded by the linker in the library itself. In general, it’s best to use one copy of the global data per application.
It’s also possible to allocate one copy of an extension’s global data for each request to load the extension, even if the same application issues multiple load requests. This type of data instantiation, called per-load instantiation, is available only when you explicitly load a shared library by calling a Code Fragment Manager routine (for example, the GetSharedLibrary function). For example, a communications application might use a shared library to implement a tool for connecting to a serial port. By requesting per-load data instantiation, you can ensure that your tool can connect to two or more serial ports simultaneously by maintaining separate copies of the tool’s data. The tool itself can then be ignorant of how many connections it’s handling.
The Code Fragment Manager honors the data allocation method recorded in the library for all import libraries that it loads automatically. This method must be either global or per context. To achieve a per-load instantiation of a library’s data or to override the instantiation method recorded in the library, you must load and prepare the library programmatically by calling Code Fragment Manager routines.
The Organization of Memory
The organization of memory in the PowerPC run-time environment is reasonably similar to the organization of memory in the 680x0 run-time environment. The system partition occupies the lowest memory addresses, with most of the remaining space allocated to the Process Manager, which creates a partition for each opened application. Moreover, the organization of an application partition in the PowerPC run-time environment is reasonably similar to the organization of an application partition in the 680x0 run-time environment. In each application partition, there are a stack and a heap, as well as space for the application’s global variables.
There are, however, a number of important differences between the PowerPC and 680x0 environments in regard to how memory is organized, both globally and in each applica-
tion’s partition. This section describes these differences. It also describes the different data alignment conventions used in each environment and the steps you might need to take to align data so that it can be exchanged between the two environments.
IMPORTANT
In general, you need the information in this section only for debugging purposes (for example, to understand where in memory your application’s code section is loaded). You might also need this information to help you determine how large to make your application partition (as specified in your application’s 'SIZE' resource).s
The two main differences between the 680x0 memory organization and the PowerPC memory organization concern the location of an application’s code section and the location of an application’s global variables. In addition, you need to pay attention to
the differing data alignment rules in each environment.
File Mapping
As you know, a PowerPC application’s executable code and global data are typically stored in a fragment container in the application’s data fork. When the application is launched, the code and data sections of that fragment are loaded into memory. The data section is loaded into the application’s heap, as described more fully in the following section. The location of the application’s code section varies, depending on whether or not virtual memory is enabled.
If virtual memory is enabled, the Virtual Memory Manager uses a scheme called file mapping to map your application’s fragment into memory: the Virtual Memory Manager uses the data fork of your application as the paging file for your application’s code section. In the 680x0 environment, all unused pages of memory are written into a single systemwide backing-store file and reread from there when needed. This often results in a prolonged application launch, because an application’s code is loaded into memory and then sometimes immediately written out to the backing-store file. In the PowerPC environment, this “thrashing” at application launch time is avoided; although the entire code fragment is mapped into the logical address space, only the needed portions of code are actually loaded into physical memory.
File mapping has additional benefits as well. The Operating System assumes that your application’s code section is always read-only. This means that, when it’s time to remove some of your application’s code from memory (to page other code or data in), the Virtual Memory Manager doesn’t need to write the pages back to the paging file. Instead, it simply purges the code from the needed pages, because it can always read the file-
mapped code back from the paging file (your application’s data fork).
IMPORTANT
Because your application’s code section is marked read-only when virtual memory is enabled, it’s not possible to write self-modifying code that will work on all PowerPC processor-based Macintosh computers.s
The virtual addresses occupied by the file-mapped pages of an application’s (or an import library’s) code are located outside both the system heap and the Process Manager’s heap. As a result, an application’s file-mapped code is never located in
the application heap itself.
Figure 1-14 illustrates the general organization of memory when virtual memory is enabled. Application partitions (including the application’s stack, heap, and global variables) are loaded into the Process Manager heap, which is paged to and from the systemwide backing-store file. Code sections of applications and import libraries are paged directly from the data fork of the application or import library file. Data sections of import libraries are put into an application’s heap for any per-context instantiations and into the system heap for any global instantiations.
Figure 1-14 Organization of memory when virtual memory is enabled
Sometimes, however, parts of your application’s executable code are loaded into your application partition, not into the file-mapped space. This happens, for example, when you store an application extension (like a filter or a tool) as a resource in your applica-
tion’s resource fork. To make the code in that extension available, you need to call the Resource Manager to load it into your application heap. Then you need to call the Code Fragment Manager to prepare the extension for execution. (See the chapter “Code Fragment Manager” in this book for a more detailed description of this way of executing resource-based code.) Because that code is loaded into your application heap, it isn’t eligible for file mapping (although it is still eligible for normal paging).
If virtual memory is not enabled, the code section of an application is loaded into the application heap. The Finder and Process Manager automatically expand your applica-
tion partition as necessary to hold that code section. The code sections of other fragments are put into part of the Process Manager’s heap known as temporary memory. If no temporary memory is available, code sections are loaded into the system heap.
IMPORTANT
It’s possible for a fragment’s code section to be loaded into the Process Manager’s heap even when virtual memory is enabled. This happens whenever the fragment resides on a device that cannot be used as a paging device. For example, applications that are located on floppy disks, AppleShare servers, and compact discs cannot be file mapped.s
Figure 1-15 illustrates the general organization of memory when virtual memory is not enabled. Application partitions (including the application’s stack, heap, and global variables) are loaded into the Process Manager heap. Code sections of applications and import libraries are loaded either into the Process Manager partition or (less commonly) into the system heap. No paging occurs.
Figure 1-15 Organization of memory when virtual memory is not enabled
The System Partition
The system partition in PowerPC processor-based Macintosh computers is organized
in essentially the same way as that in system software version 7.1 for 680x0-based computers. To support existing 680x0 applications and other software modules that access documented system global variables, the structure of much of the system partition remains unchanged. Both emulated 680x0 and native PowerPC system software compo-
nents use and maintain the system global variables. However, some undocumented system global variables have moved, and some have been eliminated altogether.
The universal header files contain declarations for routines that you can use to access virtually all of the documented system global variables. For example, you can use the routines LMGetCurDirStore and LMSetCurDirStore to get and set the value of the system global variable CurDirStore (which contains the directory ID of the current directory). LMGetCurDirStore is declared essentially as follows:
#if USESCODEFRAGMENTS
extern long LMGetCurDirStore(void);
#else
#define LMGetCurDirStore() (* (long *) 0x0398)
#endif
In any environment that uses code fragments, the function LMGetCurDirStore is defined in the system software import library that is contained in ROM. In all other environments, the function LMGetCurDirStore is defined as a macro that reads the value of the appropriate low-memory address.
By using the routines provided by the system software, you can insulate your application or other software module from any future changes in the arrangement of low memory.
Note
See the MPW interface files for a complete listing of the routines you can use to access the system global variables. You should not use the compiler flag USESCODEFRAGMENTS in your source code; if you need to know whether the Code Fragment Manager is available, you can call the Gestalt function with the selector gestaltCFMAttr.u
The only other case in which your application might be affected by changes to the system partition concerns the method you use to install exception handlers. In the 680x0 environment, there is no programmatic way to install an exception handler; instead,
you simply write the address of your exception handler into the appropriate location
in memory (as determined jointly by the kind of exception you want to handle and
the value in the microprocessor’s vector base register). A PowerPC application cannot employ this method of installing exception handlers. Instead, the system software for PowerPC processor-based Macintosh computers includes the new Exception Manager, which you should use to install native PowerPC exception handlers. See the chapter “Exception Manager” in this book for details.
Application Partitions
The organization of an application partition in the PowerPC environment is substantially simpler than in the 680x0 environment. In particular, the application partition for a PowerPC application consists only of a stack and a heap. The A5 world that occupies part of a 680x0 application partition largely is absent from the PowerPC environment. The information that is maintained in the A5 world for 680x0 applications is either no longer needed by PowerPC applications or is maintained elsewhere (usually in the application heap).
IMPORTANT
Any software that makes assumptions about the organization of an application’s A5 world will not work with PowerPC applications. For example, any 680x0 system extensions that modify an application’s jump table will need to be rewritten to work with PowerPC applications.s
This section describes the new locations for the information in a 680x0 A5 world. Although in general the arrangement of your PowerPC application partition is trans-
parent to your application, there are some instances (for example, while debugging)
in which you might need to know where in your partition information is located. In addition, if your application previously depended on some information being in its
A5 world (that is, accessed through the address in the A5 register), you will need to revise it to remove that dependence if you want to recompile your source code into
a PowerPC application. More generally, you might need to rewrite any parts of your source code that depend on information being in any of the 680x0 registers.
Note
For a more complete explanation of a 680x0 application’s A5 world,
see Inside Macintosh: Memory.u
The A5 world of a 680x0 application contains four kinds of data:
n application global variables
n application QuickDraw global variables
n application parameters
n the application’s jump table
Your 680x0 application’s jump table contains an entry for each of the application’s routines that is called by code in another segment. Because the executable code of a PowerPC application is not segmented, there is no need for a jump table in a PowerPC application partition.
IMPORTANT
The available PowerPC compilers ignore any segmentation directives
in your source code. In addition, the Segment Manager treats the UnloadSeg procedure as nonoperative.s
In PowerPC applications, the application global variables are part of the fragment’s data section, which the Code Fragment Manager loads into the application’s heap. The application global variables are always allocated in a single nonrelocatable block and are addressed through a pointer in the fragment’s table of contents.
The application parameters are 32 bytes of memory located above the application global variables that are reserved for use by the Operating System. The first 4 bytes of those parameters are a pointer to the application’s QuickDraw global variables, which contain information about the application’s drawing environment. For PowerPC applications, the application parameters are maintained privately by the Operating System. In addition, an application’s QuickDraw global variables are stored as part of the application’s global variables (in a nonrelocatable block in the application’s heap).
Because the PowerPC run-time libraries don’t implicitly define the QuickDraw global variable qd for native applications (as they do in the 680x0 environment), you’ll need to reserve space for them globally in your application and then pass the address of that memory to the InitGraf routine. You can do this by using the code shown in Listing 1-11. The data type QDGlobals is defined in the QuickDraw header files.
Listing 1-11 Declaring an application’s QuickDraw global variables
QuickDraw is one of the system software services that has been ported to native PowerPC code. It accesses the QuickDraw global variables of a 680x0 application by reading the application’s A5 value that is stored in the 680x0 context block. That value points to the boundary between the application’s global variables and the application parameters. As you’ve seen, the address of the QuickDraw global variables is the first
4 bytes of the application parameters.
Even for applications that have themselves been ported to native PowerPC code, there must be a minimal A5 world to support some nonported system software—as well as some system software patches that exist as 680x0 code—that accesses the QuickDraw global variables relative to the application’s A5 value. This mini-A5 world contains only a pointer to the application’s QuickDraw global variables, which reside in the applica-
tion’s global data section (in the application heap). The Process Manager creates a mini-A5 world for each native application at application launch time and installs its address in the 680x0 context block. As a result, the native QuickDraw can access the QuickDraw global variables of a native application in precisely the same way that it accesses the QuickDraw global variables of a 680x0 application (namely, by reading the value of the A5 register in the 680x0 context block and then finding the address of the QuickDraw global variables relative to the address of the A5 world).
The general structure of a PowerPC application partition is illustrated in Figure 1-16.
Figure 1-16 The structure of a PowerPC application partition
IMPORTANT
There is no guarantee that future versions of the run-time environment for PowerPC processor-based Macintosh computers will maintain
this arrangement of the application partition. To modify the size of
your application’s stack, for example, you should use the techniques (described in the book Inside Macintosh: Memory) that use the GetApplLimit and SetApplLimit routines. You should not directly modify system global variables (for instance, ApplLimit). Note, however, that you can specify a minimum stack size in your PowerPC application’s 'cfrg' resource. The GetApplLimit and SetApplLimit techniques are still useful if you need to adjust that minimum size dynamically. A reasonable minimum stack size for PowerPC applications is 48 KB.s
Because a PowerPC application has no A5 world (apart from the mini-A5 world main-
tained privately by the Process Manager), you don’t ever need to explicitly set up and restore your application’s A5 world. In the 680x0 environment, there are two times when you need to manage your A5 value explicitly: (1) to gain access to your application’s global variables or QuickDraw global variables from within some piece of “detached” code installed by your application (such as a Time Manager task or a VBL task) and (2) to create a 680x0 context for some other piece of code (such as a HyperCard XCMD).
In the first case, when you need to set up the A5 register for some piece of 680x0 code whose address you passed to the system software, there is no need for ported PowerPC code to set and restore the A5 register. The RTOC always points to the table of contents for the currently executing code, through which the application’s global variables can be addressed. As a result, your application’s global variables are transparently available to any code compiled into your application. To maintain a single source code base for both the 680x0 and the PowerPC environment, you can use conditional compilation. Consider the simple 680x0 VBL task defined in Listing 1-12.
Note
See the chapter “Vertical Retrace Manager” in Inside Macintosh: Processes for a complete explanation of the techniques used in Listing 1-12.u
Listing 1-12 A sample 680x0 VBL task definition
VBLRecPtr GetVBLRec (void)
= 0x2008; /*MOVE.L A0,D0*/
void DoVBL (VBLRecPtr recPtr)
{
gCounter++; /*modify a global variable*/
/*Reset vblCount so that this procedure executes again.*/
recPtr->myVBLTask.vblCount = kInterval;
}
void StartVBL (void)
{
long curA5; /*stored value of A5*/
VBLRecPtr recPtr; /*pointer to task record*/
recPtr = GetVBLRec(); /*get address of task record*/
/*Set our application's A5 and store old A5 in curA5.*/
curA5 = SetA5(recPtr->vblA5);
DoVBL(recPtr);
recPtr->myVBLTask.vblCount = kInterval;
(void) SetA5(curA5); /*restore the old A5 value*/
}
The procedure StartVBL defined in Listing 1-12 installs the A5 value of the application by calling SetA5, passing in a value that it retrieves from an expanded VBL task record. In addition, StartVBL restores the previous A5 value immediately before exiting. For VBL tasks written as PowerPC code, both of these steps are unnecessary. You can rewrite the procedure DoVBL to include those steps only conditionally, as shown in Listing 1-13. Moreover, in the 680x0 environment, the address of the VBL task record is passed in register A0. If you need that address in a high-level language, you need to retrieve it immediately upon entry to your VBL task (as is done using the GetVBLRec function in Listing 1-12). In the PowerPC environment, however, the address of the VBL task record is passed to the task as an explicit parameter. Listing 1-13 illustrates how to conditionally select the appropriate task declaration.
Listing 1-13 A conditionalized VBL task definition
/*Reset vblCount so that this procedure executes again.*/
recPtr->myVBLTask.vblCount = kInterval;
}
#if MAC68K
void StartVBL (void)
#else
void StartVBL (VBLTaskPtr recPtr)
#endif
{
#if MAC68K
long curA5; /*stored value of A5*/
VBLRecPtr recPtr; /*pointer to task record*/
recPtr = GetVBLRec(); /*get address of task record*/
/*Set our application's A5 and store old A5 in curA5.*/
curA5 = SetA5(recPtr->vblA5);
#endif
DoVBL(recPtr);
#if MAC68K
(void) SetA5(curA5); /*restore the old A5 value*/
#endif
}
Listing 1-13 also removes the dependence on the inline assembly-language code that retrieves a pointer to the VBL task record from register A0. In the PowerPC environment, information is passed to interrupt tasks as explicit parameters.
The second main case in which you need to set up and restore the A5 register is to create a 680x0 context for some existing 680x0 code (such as a stand-alone code module). To do this, you can call the SetA5 and SetCurrentA5 routines.
Note
See the book Inside Macintosh: Memory for more information on calling SetA5 and SetCurrentA5.u
Data Alignment
The PowerPC and 680x0 compilers follow different conventions concerning the alignment of data in memory. Unless told to do otherwise, a compiler arranges a data structure
in memory so as to minimize the amount of time required to access the fields of the structure. In general, this is what you’d like to have happen. In some cases, however, the processor’s preferred method of aligning data might lead to problems. Suppose, for example, that a PowerPC version of your application writes some data from memory into a file. The data is arranged in the file in exactly the same order that it was arranged
in memory, including any pad bytes that were required to achieve the desired data alignment in memory. It’s likely, however, that the resulting file will not be readable by
a 680x0 version of your application. That’s because the data will be read from the file
into a structure whose fields are very likely laid out slightly differently in memory. This section describes how this can happen, and provides some easy remedies for this kind
of problem.
A 680x0 processor places very few restrictions on the alignment of data in memory. The processor can read or write a byte, word, or long word value at any even address in memory. In addition, the processor can read byte values at any address in memory. As a result, the only padding required might be a single byte to align 2-byte or larger fields to even boundaries or to make the size of an entire data structure an even number of bytes.
Note
Remember that a word on 680x0 processors is 2 bytes;
on PowerPC processors, a word is 4 bytes.u
By contrast, the PowerPC processor prefers to access data in memory according to its natural alignment, which depends on the size of the data. A 1-byte value is always aligned in memory. A 2-byte value is aligned on any even address. A 4-byte value is aligned on any address that is divisible by 4, and so on. A PowerPC processor can access data that is not aligned on its natural boundary, but it performs aligned memory accesses more efficiently. As a result, PowerPC compilers usually insert pad bytes into data structures to enforce the preferred data alignment.
For example, consider the following data structure:
struct SampleStruct {
short version;
long address;
short count;
}
This structure occupies 8 bytes of memory in the 680x0 environment. To achieve the desired alignment of the address field in the PowerPC environment onto a 4-byte boundary, however, 2 bytes of padding are inserted after the version field. In addition, the structure itself is padded to a word boundary. As a result, the structure occupies
12 bytes of memory in the PowerPC environment.
In general, the different data alignment conventions of the 680x0 and PowerPC environments should be transparent to your application. You need to worry about the differences only when you need to transfer data between the two environments. This can happen in a number of ways:
n Your application creates files containing data structures and the user copies those files from a PowerPC processor-based Macintosh computer to a 680x0-based Macintosh computer (or vice versa).
n Your PowerPC application creates a data structure and passes it to some code running under the 68LC040 Emulator.
n Your application—running in either environment—customizes a Toolbox or Operating System data structure and passes it to the system software.
n Your PowerPC application sends data across a network connection to a 680x0-based Macintosh computer.
To ensure that data can be transferred successfully in all of these cases, it’s sufficient simply to instruct the PowerPC compiler to use the 680x0 data alignment conventions. You can do this by using a compiler pragma statement, as follows:
#pragma option align=mac68k
struct SampleStruct {
short version;
long address;
short count;
}
#pragma option align=reset
You should make sure, however, that you use 680x0 alignment only when absolutely necessary. The PowerPC processor is less efficient when accessing misaligned data than when accessing aligned data.
Alternatively, instead of forcing the compiler to use 680x0 alignment in the PowerPC environment, you can try to rearrange your data structures to promote natural
alignment in both environments. For example, you can change the declaration of the SampleStruct structure to be as follows:
struct SampleStruct {
long address;
short count;
short version;
}
A PowerPC compiler does not insert any pad bytes into the SampleStruct structure
in this new arrangement, because the fields are already aligned along the desired memory boundaries.
Note
Your PowerPC compiler may use slightly different alignment methods than those described here. Consult your development system’s documentation for complete information. For more details on specifying alignment methods with the PPCC compiler, see the book Macintosh on PowerPC C Compiler.u
You also need to be careful when passing floating-point data between the 680x0 and PowerPC environments. The most efficient floating-point data type in the 680x0 environ-
ment is the 80-bit (or 96-bit) extended data type. The most efficient data types in the PowerPC environment are single, double, and long double, which are 32, 64, and 128 bits, respectively. The PowerPC Numerics library includes routines you can use to convert among these various data types. See Inside Macintosh: PowerPC Numerics for complete details.
Compatibility and Performance
In general, it’s relatively easy to modify existing ANSI-compliant C or C++ source code that successfully compiles and runs on 680x0-based Macintosh computers so that it can be compiled and run on PowerPC processor-based Macintosh computers. Most of the intricate work required to make your application compatible with the new PowerPC run-time environment is performed automatically by your development system’s compiler and linker and by the Code Fragment Manager. As you’ve seen, the changes you need to make in your application’s source code are fairly straightforward. You need to make these changes:
n Create routine descriptors for any routines whose addresses you pass to code of an unknown type.
n Minimize any dependencies on system global variables by using the new set of accessor routines defined in the MPW interface files.
n Isolate and conditionalize any dependencies on specific features of the 680x0 A5 world or the 680x0 run-time environment.
n Isolate and conditionalize any dependencies on information being passed in specific 680x0 registers.
n Use 680x0 alignment for any data that is passed between environments, or declare your data structures so that their fields are aligned identically in both the 680x0 and PowerPC environments.
This section discusses several additional topics that relate more generally to the compatibility and performance of your PowerPC application.
Patches
Some applications or other kinds of software patch the Operating System’s trap dispatch tables to augment or replace the capabilities of certain system software routines. In general, however, there is much less need to patch the system software now than there previously was, and you should avoid doing so if at all possible. One very good reason to avoid unnecessary patching is that you can incur a substantial performance reduction if your patch causes a mode switch. For example, when a PowerPC application calls
a system software routine that is implemented as PowerPC code, the dispatching to
the PowerPC code occurs fairly quickly. However, if you patch the PowerPC code
with 680x0 code, the Mixed Mode Manager needs to intervene to switch the execution environments both when entering and when exiting your patch code. This switching results in a considerable overhead (approximately 15 microseconds on a 60 MHz PowerPC processor per round-trip mode switch, the equivalent of about fifty 680x0 instructions).
Note
The precise number of instructions or microseconds of overhead required to switch from one environment to the other and back is subject to change in future system software versions and on different hardware configurations. The important point to keep in mind is that switching modes is a reasonably expensive activity and you should avoid it whenever possible.u
The same situation occurs if you use PowerPC code to patch a system software routine that is implemented as 680x0 code. Once again, a mode switch is required before entering your patch code and after exiting it.
The ideal solution is simply to avoid patching the system software entirely. In the few cases in which you absolutely cannot avoid patching some system software routine, you can avoid the kind of mode switching just described by making sure to patch PowerPC code with a PowerPC patch and 680x0 code with a 680x0 patch. Because you cannot in general know what kind of code implements a particular system software routine, you should install a fat patch, which addresses both PowerPC and 680x0 versions of your code. To install a fat patch, you need to create a routine descriptor with two embedded routine records, one record describing the PowerPC routine and one record describing the 680x0 routine. Then you pass the address of that routine descriptor—that is, a universal procedure pointer—to an appropriate Trap Manager routine, which installs that universal procedure pointer into the trap dispatch table. When the patched routine is called, the Mixed Mode Manager inspects the routine descriptor addressed by the universal procedure pointer and selects the patch code that has the smallest impact on performance.
IMPORTANT
IMPORTANT
To install patches, you can use one of the Trap Manager routines SetToolTrapAddress, SetOSTrapAddress, and NSetTrapAddress. You should not use the obsolete routine SetTrapAddress. See the chapter “Trap Manager” in Inside Macintosh: Operating System Utilities for a more complete description of the recommended way to patch system software routines. You should never manipulate the trap dispatch tables directly.s
Your patch code should, of course, make sure to call through to the code originally addressed by the entry in the trap dispatch table. You can retrieve that address by calling GetToolTrapAddress, GetOSTrapAddress, or NGetTrapAddress before you install
your patch. In the 680x0 patch code, you can simply jump to that address. In the PowerPC patch code, you execute the original code by calling the Mixed Mode Manager routine CallUniversalProc (for Toolbox traps) or CallOSTrapUniversalProc (for Operating System traps).
The CallOSTrapUniversalProc function behaves just like the CallUniversalProc function except that it preserves additional 680x0 registers around the execution of
the called procedure. In addition, you need to pass it a value specifying the trap word. Operating System traps expect a 2-byte parameter in register D1; this parameter represents the actual A-trap word used to call the routine. (Some traps use bits in the trap word to dispatch to different code.) Any Operating System trap patches you install should accept that parameter in register D1 and pass it through when calling the original trap code. Listing 1-14 shows how to patch the NewPtr function using PowerPC code.
Listing 1-14 Patching an Operating System trap
enum { /*procedure information for NewPtr function*/
Because CallUniversalProc and CallOSTrapUniversalProc are called as subroutines and return control to the calling code, all PowerPC patches are both
head patches and tail patches (that is, your patch has control both before and after
the code originally pointed to by the trap dispatch table).
Notice that the address you call through to might be the address of someone else’s patch. As a result, it’s still possible for mode switches to occur, if at least one link in the patch daisy chain is not a fat patch. These mode switches are unavoidable.
Note also that the system software includes a small number of split traps, system software routines that are implemented with 680x0 code (usually in ROM) and as PowerPC code in an import library. Because the PowerPC code is contained directly
in the import library, you cannot patch the PowerPC portion of a split trap. In general, however, only those routines are implemented as split traps that are not likely candi-
dates for patching. For example, a number of very small utility routines like AddPt and SetRect are implemented as split traps.
The biggest restriction on patching is that you cannot patch any selector-based traps (system software routines that are dispatched through a selector code) with either pure PowerPC or fat patches. In the 680x0 environment, you can patch one or more selectors belonging to a dispatched trap and pass all others through to the original code. In the PowerPC environment, however, this is not possible. As a result, when patching with PowerPC code, you must patch all the routines selected by a single trap if you patch any of them. However, you cannot in general determine how many selectors are supported by a given selector-based trap. You cannot therefore safely patch selector-based traps in a way that is likely to remain compatible with future system software versions. For now, you should use 680x0 code if you need to patch selector-based traps.
The Memory Manager
As you’ve already learned, the Memory Manager has been rewritten for PowerPC processor-based Macintosh computers. The new Memory Manager, written in C and compiled into native PowerPC code, offers much better performance than the previous 680x0 assembly-language version, both because it runs in the native PowerPC environ-
ment and because it uses substantially improved algorithms to manage heaps. In general, however, the application programming interface has not changed. As a result, you’ll benefit from the new version completely transparently, whether your application runs under the 68LC040 Emulator or in the native PowerPC environment.
The Memory control panel (shown in Figure 1-17) includes controls that allow the user to select whether applications and other software use the new Memory Manager or the original Memory Manager. By default, the new (or “Modern”) Memory Manager is used.
Figure 1-17 The Memory control panel for PowerPC processor-based Macintosh computers
There are, however, several restrictions imposed by the new Memory Manager that might cause compatibility problems for your application. If you’ve followed the advice and warnings in the book Inside Macintosh: Memory, your application should run without problems. However, the new Memory Manager is generally much less forgiving toward code that fails to heed those warnings. Here are some areas to watch out for.
n Don’t dispose of blocks more than once. When you dispose of a block, whether relocatable or nonrelocatable, the Memory Manager immediately takes control of that block. Any future attempt to operate on the block (even simply to dispose of it) is likely to cause problems. Note that it’s possible to dispose of a block twice in rather subtle ways. For example, you might call GetPicture to display a picture stored in a resource and then inadvertently call KillPicture or DisposeHandle to remove it. This way of disposing of the block of memory leaves the 'PICT' resource in the resource map. When your application quits, the resource is disposed of once again. (The proper way to dispose of a picture loaded from a resource is to call ReleaseResource.)
n Don’t manipulate the Memory Manager’s private data structures, including block headers for both relocatable and nonrelocatable blocks, zone headers, and any unused master pointers. The sizes and formats of some of these structures have changed.
n Don’t access any system global variables maintained by the Memory Manager. Whenever possible, use the documented application programming interface (such
as the SetApplLimit and SetGrowZone procedures) to avoid manipulating
those variables.
n Don’t modify free blocks of data or rely on the integrity of any data in free blocks. The new Memory Manager assumes control of all unallocated memory in your heap and may overwrite any information in free blocks.
n Don’t close a resource file without first detaching any resources in that file that you want to continue using. To detach a resource, call the DetachResource procedure.
n Don’t use fake handles or pointers. You should call Memory Manager routines
only on blocks that were created by the Memory Manager itself. Remember that
the Memory Manager is fundamentally a heap managing tool. You should not,
for example, call DisposePtr on data in your stack or in your application global variable space.
n Don’t call Memory Manager routines at interrupt time. Except for the BlockMove procedure, all Memory Manager routines either move memory or manipulate system global variables. These operations must not occur at interrupt time.
n Make sure to flush the instruction cache whenever necessary. Because it’s much harder to treat data as executable code in the PowerPC environment, the new Memory Manager flushes the instruction cache only when it moves blocks around in memory.
n Don’t make assumptions about the relative positions of the stack and heap in your application partition. You should adjust the size of the stack, if necessary, by calling GetApplLimit and SetApplLimit.
To repeat, you shouldn’t encounter any of these problems if you’ve used the routines and programming techniques documented in Inside Macintosh: Memory.
Performance Tuning
Once you’ve gotten your application or other software to execute correctly on a PowerPC processor-based Macintosh computer, you’ll want to spend some time
tuning it for maximum performance. Many factors affect the speed at which code executes, including
n how often you cause mode switches from one environment to another
n how you pass parameters to subroutines
n whether you use compiler-specific optimizations
The easiest way to increase the performance of your application is to use the compiler’s optimization capabilities. It’s not uncommon for compiler speed optimizations to improve your code’s execution by as much as 50 percent. See the book Macintosh on PowerPC C Compiler for more information on compiler optimizations.
This section provides some preliminary discussion of the overhead associated with mode switches and parameter passing. In general, you’ll need to combine the informa-
tion presented here with empirical observations you obtain when using a performance-
measurement tool, such as the Adaptive Sampling Profiler (ASP) built into the debugger. See the book Macintosh Debugger Reference for complete information about using the ASP.
Mode Switches
You’ve already learned (in “Patches” on page 1-66) that it’s important to avoid mode switches whenever possible. The Mixed Mode Manager requires the equivalent of approximately fifty 680x0 instructions to switch from one environment to another.
As a result, you might want to minimize the number of times your code invokes a
mode switch.
Some mode switches are entirely avoidable. For example, if you need to patch a system software routine, you can avoid at least some mode switching by installing a fat patch
(a patch that includes both 680x0 and PowerPC versions of the patching code). Similarly, if your application calls any resource-based code (for example, dynamically loadable filters), you can create fat resources: code resources that include both 680x0 and PowerPC versions of the executable code. Once again, the Mixed Mode Manager will select the code that minimizes mode switching.
Some mode switches, however, are entirely unavoidable. Any time your PowerPC application calls a system software routine that has not yet been ported to use the native PowerPC instruction set, the Mixed Mode Manager must switch to the 680x0 environ-
ment to execute the routine and then switch back to the PowerPC environment to allow your application to continue. This sometimes means that parts of your application might execute more slowly on a PowerPC processor-based Macintosh computer than on a 680x0-based Macintosh computer.
A good example of this behavior concerns calling Event Manager routines, which remain as 680x0 code in the first release of the system software for PowerPC processor-based Macintosh computers. Suppose that during a lengthy calculation your application calls WaitNextEvent or EventAvail to scan the event queue for a Command-period event (which typically indicates that the user wants to cancel the lengthy operation) and to give time to other applications. Each time you call the Event Manager, two mode switches occur (from your code to the emulated code and back). Moreover, because your code is native PowerPC code, it executes more quickly between Event Manager calls than it did in the 680x0 environment. The result is that your application is switching modes more often than it absolutely has to.
Although you cannot avoid the mode switches entirely when calling the Event Manager, you can lessen the overall impact of those switches on your application’s performance by doing more work between successive Event Manager calls. One simple way to do this is to perform more than one iteration of a loop between calls to WaitNextEvent. Another simple way is to call WaitNextEvent only after a certain amount of time has elapsed. Listing 1-15 shows how you can rewrite a part of your main event loop to incorporate this feature.
Listing 1-15 Waiting to call the WaitNextEvent function
static unsigned long gWNEDelay = 5; /*adjust this value as needed*/
void MainEventLoop(void)
{
EventRecord myEvent;
unsigned long nextTimeToCheckForEvents = 0;
while (!gDone) {
if ((gWNEDelay == 0) || (TickCount() > nextTimeToCheckForEvents)) {
As you can see, this code continues in the event loop only when a certain amount of time has elapsed. This method of adjusting the frequency of calls to WaitNextEvent works on any available Macintosh computer and doesn’t require any conditional compilation.
Routine Parameters
You’ve already learned (in “Parameter Passing” beginning on page 1-47) that PowerPC compilers attempt to pass as many parameters as possible in the processor’s registers, thereby minimizing the number of memory accesses that are required for a routine call. You can, however, help the compiler minimize memory accesses by following a few simple guidelines:
n Use function prototypes. A compiler can generate more efficient code if you include prototypes for any functions that accept floating-point parameters. The compiler then knows to use the floating-point registers to store those parameters. If no function prototype is available for a function taking floating-point parameters, the compiler needs to pass the same information in both general-purpose and floating-point parameters. (For more information, see the description of PowerPC calling conventions beginning on page 1-47.)
n Put floating-point parameters at the end of the parameter list. A PowerPC compiler reserves space for floating-point parameters not only in the floating-point registers but also either in the general-purpose registers or in a stack frame. (This is necessary to support passing floating-point parameters to a function for which no prototype
is available.) It’s best to let any non-floating-point parameters use the available general-purpose register, so you should move floating-point parameters to the end of the routine’s parameter list.
n Minimize the use of variable parameter lists. For many reasons, it’s inefficient to
use variable parameter lists in the PowerPC environment. Use them only when absolutely necessary.
IMPORTANT
These floating-point parameter-passing optimizations are highly dependent on specific features of the PowerPC run-time environment. You should implement these guidelines only in those parts of your code where maximum efficiency is necessary.s
Listing 2-0
Table 2-0
Mixed Mode Manager
Contents
About the Mixed Mode Manager2-4
External Code2-4
Procedure Pointers2-5
Mode Switches2-7
Calling PowerPC Code From 680x0 Code2-8
Calling 680x0 Code From PowerPC Code2-12
Using the Mixed Mode Manager2-14
Specifying Procedure Information2-14
Using Universal Procedure Pointers2-21
Using Static Routine Descriptors2-22
Executing Resource-Based Code2-24
Mixed Mode Manager Reference2-26
Constants2-27
Routine Descriptor Flags2-27
Procedure Information2-27
Routine Flags2-34
Instruction Set Architectures2-35
Data Structures2-36
Routine Records2-36
Routine Descriptors2-37
Mixed Mode Manager Routines2-38
Creating and Disposing of Routine Descriptors2-39
Calling Routines via Universal Procedure Pointers2-42
Determining Instruction Set Architectures2-44
Summary of the Mixed Mode Manager2-45
C Summary2-45
Constants2-45
Data Types2-48
Mixed Mode Manager Routines2-49
Mixed Mode Manager
This chapter describes the Mixed Mode Manager, the part of the Macintosh system software that manages the mixed-mode architecture of PowerPC processor-based computers running 680x0-based code (including system software, applications, and stand-alone code modules). The Mixed Mode Manager cooperates with the 68LC040 Emulator to provide a fast, efficient, and virtually transparent method for code in
one instruction set architecture to call code in another architecture. The Mixed Mode Manager handles all the details of switching between architectures.
The Mixed Mode Manager is intended to operate transparently to most applications and other software. You need the information in this chapter only if
n you want to recompile your application into PowerPC code and your application passes the address of some routine to the system software using a reference of
type ProcPtr
n your application—written in either PowerPC or 680x0 code—supports installable code modules that might be written in a different architecture
n you are writing stand-alone code (for example, a VBL task or a component) that could be called from either the PowerPC native environment or the 680x0 emulated environment
n you are writing a debugger or other software that needs to know about the structure of the stack at any time (for example, during a mode switch)
You do not need to read this chapter if you’re simply writing 680x0 code that doesn’t call external code modules of unknown type, or if you are writing PowerPC code that calls other PowerPC code using a procedure pointer. In these cases, any environment switching that might occur is handled completely transparently by the Mixed Mode Manager.
IMPORTANT
This chapter describes the operation and features of the Mixed
Mode Manager and the 68LC040 Emulator as they exist in the
first version of the system software for PowerPC processor-based
Macintosh computers.s
To use this chapter, you should already be generally familiar with the Macintosh Operating System. See the books Inside Macintosh: Processes and Inside Macintosh: Memory for information about the run-time architecture of the 680x0 environment. You also need to be familiar with the run-time architecture of PowerPC processor-based Macintosh computers, as explained in the chapter “Introduction to PowerPC System Software.”
This chapter begins by describing the mixed-mode architecture of PowerPC processor-
based Macintosh computers and the operations of the Mixed Mode Manager. Then it shows how to use the Mixed Mode Manager to call external code.
About the Mixed Mode Manager
The Mixed Mode Manager is the part of the Macintosh Operating System that allows PowerPC processor-based Macintosh computers to cooperatively run 680x0 applications, PowerPC applications, 680x0 system software, and PowerPC system software. It provides a number of capabilities, including
n transparent access to 680x0-based system software from PowerPC applications
n transparent access to PowerPC processor-based system software from 680x0 applications
n a method—independent of the instruction set architecture—of calling an external piece of code. This includes
n transparent access to PowerPC code by 680x0 applications
n system support for calling 680x0 code from PowerPC code
n system support for calling PowerPC code from 680x0 code
n support for patching PowerPC or 680x0 code with PowerPC or 680x0 code
n support for stand-alone code resources containing either 680x0 or PowerPC code
In short, the Mixed Mode Manager is intended to provide both PowerPC processor-
based and 680x0-based code transparent access to code written in another instruction set (or in an instruction set whose type is unknown). It does this by keeping track of what kind of code is currently executing and, when necessary, switching modes. For example, if some PowerPC code calls a Macintosh Operating System routine that exists only in 680x0 form, the Mixed Mode Manager translates the routine’s parameters from their PowerPC arrangement (for example, stored in registers GPR3 and GPR4) into the appropriate 680x0 arrangement (for example, stored in registers D0 and D1, with the result placed into register A0).
The Mixed Mode Manager is an integral part of the system software for PowerPC processor-based Macintosh computers. It is designed to hide, as much as possible, the dual nature of the operating environment supported on PowerPC processor-based Macintosh computers running the 68LC040 Emulator. Except in specific cases described later, your application or other software should not need to call the routines provided by the Mixed Mode Manager.
External Code
To appreciate when and why you might need to use the routines provided by the Mixed Mode Manager, you need to understand the circumstances in which you might directly or indirectly call code in an instruction set architecture different from that of the calling code. There are several ways to execute external code (code that is not directly contained in your application or software), including
n calling a trap
n calling a device driver (for example, by calling the driver’s Open, Status, or
Control routines)
n loading and then executing code contained in a resource
n using the address of a procedure or function obtained from an unknown source
In any of these four cases, the external code that you call might be in an instruction set architecture that is different from the instruction set architecture of the calling code. (For example, an application that uses the PowerPC instruction set might call a ROM-based Toolbox trap that uses the 680x0 instruction set.) As a result, in all these cases, the Mixed Mode Manager might have to switch environments to allow the called routine to execute and then switch back to allow your application or other software to continue execution.
In the first two of the four cases, the Mixed Mode Manager is able to handle all required mode switching virtually transparently to the calling software. In the two last cases, however, you might need to intervene in the otherwise automatic operations of the Mixed Mode Manager. This is because the Mixed Mode Manager cannot tell, from a given pointer to some executable code, what kind of code the pointer references.
The following section describes in greater detail the extent of this problem and the way you need to solve it, using universal procedure pointers in place of procedure pointers. See “Using the Mixed Mode Manager” beginning on page 2-14 for code samples that illustrate how to create and use universal procedure pointers.
Procedure Pointers
For present purposes, a procedure pointer is any reference generated by a compiler when taking the address of a routine. On 680x0-based Macintosh computers, a procedure pointer is simply the address of the routine’s executable code (and is defined by the ProcPtr data type). On PowerPC processor-based Macintosh computers, a procedure pointer is the address of the routine’s transition vector. Figure 2-1 illustrates the structure of procedure pointers in each environment.
Figure 2-1 680x0 and PowerPC procedure pointers
A transition vector is a set of two addresses: the address of the routine’s executable code and the address of the fragment’s table of contents (TOC).
The Macintosh programming interfaces allow you to use procedure pointers in several ways. A procedure pointer can be
n passed as a parameter to a system software routine (for example, the growZone parameter to the SetGrowZone routine)
n passed in a field of a parameter block or other data structure (for example, the gzProc field of a Zone parameter block)
n stored in an application-specific global data structure (for example, the addresses stored in a grafProcs field of a graphics port)
n installed into a vector accessed through system global variables (for example, the jGNEFilter global variable)
n installed into the trap dispatch table or into a patch daisy chain using the SetToolTrapAddress or SetOSTrapAddress routine
As indicated previously, the Mixed Mode Manager cannot tell, from a given procedure pointer, what kind of code the pointer references (either directly through a pointer of type ProcPtr or indirectly through a transition vector). The Mixed Mode Manager solves this problem by requiring you to use generalized procedure pointers, known as universal procedure pointers, whenever you would previously have used a procedure pointer. A universal procedure pointer is either a normal 680x0 procedure pointer
(that is, the address of a routine) or the address of a routine descriptor, a data structure that the Mixed Mode Manager uses to encapsulate information about an externally referenced routine. A routine descriptor describes the address of the routine, its parameters, and its calling conventions.
typedef RoutineDescriptor *UniversalProcPtr;
Note
See “Routine Descriptors” on page 2-37 for a description
of the fields of a routine descriptor.u
The Macintosh application programming interfaces have been revised for the PowerPC platform to change all references to procedure pointers to references to universal procedure pointers. (The new interfaces are called the universal interface files.) For example, the SetGrowZone function was previously declared in the interface file Memory.h like this:
This redefinition of all procedure pointers as universal procedure pointers ensures that at the time a procedure is to be executed, the Operating System has enough information
to determine the routine’s instruction set architecture and hence to determine whether
a mode switch is necessary. In addition, if a mode switch is necessary, the universal procedure pointer (if it is a pointer to a routine descriptor) provides information about the routine’s calling conventions, the number and sizes of its parameters, and so forth.
It’s important to understand exactly when you need to be concerned about routine descriptors and when you need to use the new programming interfaces when writing your application. The following cases cover most of the relevant possibilities:
n If your application uses the 680x0 instruction set (and therefore executes under the 68LC040 Emulator on PowerPC processor-based Macintosh computers) and does not support external code modules, you do not need to use routine descriptors or the new programming interfaces.
n If your application uses the PowerPC instruction set, you must use the new program-
ming interfaces.
n If your application uses either the 680x0 instruction set or the PowerPC instruction set and makes calls only to code of the same type, you do not need to create routine descriptors.
n If your code uses the PowerPC instruction set and passes a routine’s address to code that might be in the 680x0 instruction set, then you need instead to pass the address of a routine descriptor. This applies to all the methods of passing a routine address listed earlier in this section (as a parameter to a system software routine, in a field of a parameter block, and so forth).
n If you create a resource containing PowerPC code that might be called either by 680x0 code or by PowerPC code, that code must be preceded by a routine descriptor. It’s possible that the calling code simply loads the resource and jumps to its beginning;
if the resource does not begin with a routine descriptor, the Mixed Mode Manager
will not be called to determine whether a mode switch is necessary. See “Executing Resource-Based Code” on page 2-24 for more details.
IMPORTANT
In short, you need to convert procedure pointers to universal procedure pointers only if you pass a routine’s address to code that is external to your application. See “Using Universal Procedure Pointers” beginning on page 2-21 for details on making the appropriate modifications to your application.s
Mode Switches
This section describes the operations of the Mixed Mode Manager in switching modes (from PowerPC native mode to 680x0 emulation mode, or vice versa). It describes the circumstances under which mode switches are performed and the mechanism that the Mixed Mode Manager uses to switch modes.
IMPORTANT
The information in this section is provided for debugging purposes only. Your application (or other code) should not rely on the details of mode switching presented here.s
Every mode switch occurs as a result of either an explicit or an implicit cross-mode
call. An explicit cross-mode call occurs when the calling software itself calls the CallUniversalProc function and passes a universal procedure pointer of a routine that exists in an instruction set architecture other than that of the caller. An implicit cross-mode call occurs when the calling software executes a routine descriptor for a routine that exists in an instruction set architecture other than that of the caller.
The mixed-mode architecture of PowerPC processor-based computers running 680x0-
based code gives rise to four possible situations when a piece of code calls a system software routine:
n When 680x0 code calls a system software routine that exists as 680x0 code, the
routine is called directly, using the trap dispatch mechanism provided in the
68LC040 Emulator.
n When 680x0 code calls a system software routine that exists as PowerPC code, the routine is called indirectly, using the address—contained in the trap dispatch table—of a routine descriptor, which invokes a mode switch to the PowerPC environment. When the PowerPC code returns, the executing environment is switched back to the 68LC040 Emulator. See the next section, “Calling PowerPC Code From 680x0 Code,” for more details.
n When PowerPC code calls a system software routine that exists as PowerPC code, the routine is called through glue in the system software import library. The glue code calls CallUniversalProc, which determines that the routine is PowerPC code and then calls it directly.
n When PowerPC code calls a system software routine that exists as 680x0 code, the routine is called through glue code contained in the system software import library. The glue code sets up a 680x0 universal procedure pointer (which is simply a 680x0 procedure pointer) and executes the 680x0 code by calling the CallUniversalProc function. See “Calling 680x0 Code From PowerPC Code” on page 2-12 for more details.
IMPORTANT
Only 680x0 code can make implicit cross-mode calls. Native PowerPC code must always make explicit cross-mode calls. The Mixed Mode Manager determines whether a mode switch is necessary.s
Calling PowerPC Code From 680x0 Code
This section describes how the Mixed Mode Manager switches modes from the 680x0 emulated environment to the PowerPC native environment. This usually happens
when 680x0 code calls a system software routine that is implemented in the PowerPC instruction set.
Suppose that a 680x0 application calls some system software routine. The application is not aware that it is running under the 68LC040 Emulator, so it just pushes the routine’s parameters onto the stack (or stores them into registers) and then jumps to the routine
or calls a trap that internally jumps to the routine. If the routine exists as 680x0 code,
no mode switch is required and the routine is called as usual. If, however, the routine exists as PowerPC code, the calling application must implicitly invoke the Mixed
Mode Manager.
If the calling application merely jumps to the PowerPC code, the code must begin with
a routine descriptor, as explained in “Executing Resource-Based Code” on page 2-24. If the calling application calls a trap, the trap dispatch table must contain—instead of the address of the routine’s executable code—the address of a routine descriptor for that routine. This routine descriptor is created at system startup time.
Figure 2-2 shows the path followed when a 680x0 application calls a system software routine implemented as PowerPC code. The trap dispatch table contains the address
of the native routine’s routine descriptor. The routine descriptor contains the address
of the routine’s transition vector, which in turn contains the routine’s entry point and TOC value.
Figure 2-2 Calling PowerPC code from a 680x0 application
For example, suppose that your application calls the CountResources function,
as follows:
myResCount = CountResources('PROC');
Suppose further that CountResources has been ported to the PowerPC instruction set. When your application calls CountResources, the stack looks like the one shown in Figure 2-3.
Figure 2-3 The stack before a mode switch
The trap dispatcher executes the CountResources routine descriptor, which begins with an executable instruction that invokes the Mixed Mode Manager. The Mixed Mode Manager retrieves the transition vector and creates a switch frame on the stack. A switch frame is a stack frame that contains information about the routine to be executed, the state of various registers, and the address of the previous frame. Figure 2-4 shows the structure of a 680x0-to-PowerPC switch frame.
IMPORTANT
Notice in Figure 2-4 that the low-order bit in the back chain pointer to the saved A6 value is set. The Mixed Mode Manager uses that bit internally as a signal that a switch frame is on the stack. The Mixed Mode Manager will fail if the stack pointer has an odd value.s
Figure 2-4 A 680x0-to-PowerPC switch frame
In addition to creating a switch frame, the Mixed Mode Manager also sets up several CPU registers:
n The Table of Contents Register (RTOC) must be set to the TOC address of the fragment containing the CountResources routine. This value is obtained from
the transition vector whose address is extracted from the routine descriptor.
n The Link Register (LR) must be set to point to code that cleans up the stack and restarts the emulator.
At this point, it’s safe to execute the native CountResources code. When CountResources completes, the Mixed Mode Manager copies the return value from R3 into its proper location (in a register or on the stack). The RTOC, LR, and CR are restored to their saved values, and the switch frame is popped off the stack. The Mixed Mode Manager also pops the return address off the stack, as well as the parameters of routines of type pascal. Finally, the Mixed Mode Manager jumps back into the 68LC040 Emulator and the application continues execution.
Calling 680x0 Code From PowerPC Code
This section describes how the Mixed Mode Manager switches modes from the PowerPC native environment to the 680x0 emulated environment. This usually happens when PowerPC code calls a system software routine that is implemented in the 680x0 instruction set.
For example, suppose that a PowerPC application calls a system software routine that exists only as 680x0 code. In the system software import library must exist a small piece of glue code that
n allocates space on the stack for the routine’s result, if any
n determines the address of the 680x0 routine from the trap dispatch table
n provides the procedure information for the routine
n calls the CallUniversalProc function
Listing 2-1 illustrates a sample glue routine for the QuickDraw text-measuring routine TextWidth.
IMPORTANT
Glue routines like the one illustrated in Listing 2-1 are part of
the system software import library. You do not need to write
glue routines like this.s
Listing 2-1 Sample glue code for a 680x0 routine
enum {
uppTextWidthProcInfo = kPascalStackBased
| RESULT_SIZE(kTwoByteCode)
| STACK_ROUTINE_PARAMETER(1, kFourByteCode)
| STACK_ROUTINE_PARAMETER(2, kTwoByteCode)
| STACK_ROUTINE_PARAMETER(3, kTwoByteCode)
};
short TextWidth (Ptr textBuf, short firstByte, short byteCount)
See “Specifying Procedure Information” beginning on page 2-14 for a description of the constants and macros used to define the procedure information (that is, the myProcInfo parameter).
Note
For Operating System traps (that is, traps of type OSTrap), the
trap dispatcher copies the trap number into register D1. As a result,
the glue code illustrated in Listing 2-1 would need to call the
function CallOSTrapUniversalProc.u
The call to CallUniversalProc invokes the Mixed Mode Manager, which verifies that a mode switch is necessary. At that point, the Mixed Mode Manager saves all nonvolatile registers and other necessary information on the stack in a switch frame. Figure 2-5 shows the structure of a PowerPC-to-680x0 switch frame.
Figure 2-5 A PowerPC-to-680x0 switch frame
Once the switch frame is set up, the Mixed Mode Manager sets up the 68LC040 Emulator’s context block and then jumps into the emulator. When the routine has finished executing, it attempts to jump to the return address pushed onto the stack. That return address points to a mode-switching structure contained in the Reserved area in the switch frame. The emulator encounters the instruction in the goMixedModeTrap field of the routine descriptor and then saves the current 680x0 state in its context block. Once this is done, the Mixed Mode Manager restores native registers that were previously saved and deallocates the switch frame. Control then returns to the caller of CallUniversalProc.
IMPORTANT
As currently implemented, the instruction that causes a return from the 68LC040 Emulator to the native PowerPC environment clears the low-order 5 bits of the Condition Code Register (CCR). This prevents 680x0 callback procedures from returning information in the CCR. If you want to port 680x0 code that calls an external routine that returns results in the CCR, you must instead call a 680x0 stub that saves that information in some other place.s
Using the Mixed Mode Manager
You can use the Mixed Mode Manager to specify the procedure information for a routine, create routine descriptors, and execute the code referenced by a universal procedure pointer. Typically, you’ll call NewRoutineDescriptor to create a routine descriptor and CallUniversalProc to execute the code described by a routine descriptor. You can dispose of routine descriptors you no longer need by calling the DisposeRoutineDescriptor function.
Remember that if you are compiling code for the 680x0 environment, you don’t need to worry about creating, calling, or disposing of routine descriptors. For 680x0 code, the compiler variable USESROUTINEDESCRIPTORS is set to false (the default setting). Any calls in your source code to the NewRoutineDescriptor function are replaced by the code address passed as a parameter to NewRoutineDescriptor. Similarly, any calls to DisposeRoutineDescriptor are simply removed.
Note
Your development environment sets the USESROUTINEDESCRIPTOR variable to the value appropriate for the kind of code you are compiling, You don’t need to set or reset this variable.u
Specifying Procedure Information
The primary task of the Mixed Mode Manager is to convert routine parameters between the 680x0 and PowerPC environments. The parameter passing conventions in the PowerPC environment are identical for all routines, so you’ll need to specify the calling conventions only for 680x0 routines.
In the Macintosh Operating System, there are five basic kinds of calling conventions:
n Pascal routines with the parameters passed on the stack
n C routines with the parameters passed on the stack
n routines with the parameters passed in registers
n dispatched Pascal or C routines with the selector in a register and the parameters on the stack
n dispatched Pascal routines with the selector and the parameters on the stack
In addition to these five basic kinds of calling conventions, there exist a number of cases that the Mixed Mode Manager treats specially. For example, an ADB service routine is passed information in registers A0, A1, A2, and D0.
The Mixed Mode Manager uses a long word of type ProcInfoType to encode a routine’s procedure information, which contains essential information about the calling conventions and other features of a routine. You need to specify procedure information when you create a new routine descriptor by calling the NewRoutineDescriptor function.
typedef unsigned long ProcInfoType;
IMPORTANT
In all likelihood, you do not need to read the remainder of this section, which explains in detail the structure of the ProcInfoType long word and shows how to create custom procedure information. The universal interface files define procedure information for each universal procedure pointer used by the system. For example, the interfaces define the constant uppGrowZoneProcInfo for you to use when specifying
the procedure information for a grow-zone function. You need to create procedure information only for routines not defined in the programming interfaces. You can probably skip to the section “Using Universal Procedure Pointers” on page 2-21.s
The lower-order 4 bits of the procedure information encode the routine’s calling conventions. You specify calling conventions using these constants:
For example, a routine that passes its parameters on the stack according to normal C language conventions would have the rightmost 4 bits of the procedure information set to 0001 (hexadecimal 0x00000001).
Except for routines having calling conventions of type kSpecialCase, the 2 bits to the left of the calling convention bits encode the size of the result returned by the routine. You can access those bits using a constant:
#define kResultSizePhase 4
The Mixed Mode Manager provides four constants and a macro that you can use to set a routine’s result size in its procedure information.
enum {
kNoByteCode = 0,
kOneByteCode = 1,
kTwoByteCode = 2,
kFourByteCode = 3
};
#define RESULT_SIZE(sizeCode) \
((ProcInfoType)(sizeCode) << kResultSizePhase)
Except as already noted, every set of procedure information uses its rightmost 6 bits to specify the calling conventions and result size information. The calling conventions, which take up the rightmost 4 bits, determine how the remaining bits of a routine’s procedure information are interpreted. For example, if the rightmost 4 bits contain
the value kCStackBased or the value kPascalStackBased, then the remaining bits encode the sizes and number of the parameters passed on the stack. Figure 2-6 shows how the Mixed Mode Manager interprets the procedure information for a stack-
based routine.
Figure 2-6 Procedure information for a stack-based routine
Once again, the Mixed Mode Manager provides a set of constants and macros that you can use to specify a stack-based routine’s procedure information.
As you can see, the maximum number of stack-based parameters whose sizes you can specify using a variable of type ProcInfoType is 13. The procedure information encoding used by the Mixed Mode Manager places limits on the number of specifiable register-based parameters as well. See Table 2-1 at the end of this section (page 2-20) for a complete list of these limits.
The new application programming interface files described earlier (on page 2-6) include constants that define procedure information for each type of routine to which you might need to create a universal procedure pointer. For example, the interface file Memory.h includes these definitions:
A grow-zone function follows normal Pascal calling conventions, returns a value that is 4 bytes long, and takes a single 4-byte parameter on the stack. A purge-warning procedure follows normal Pascal calling conventions, returns no value, and takes a single 4-byte parameter on the stack.
The Mixed Mode Manager provides similar constants and macros for specifying procedure information for register-based routines.
For example, Figure 2-7 shows the arrangement of the procedure information for a register-based routine.
Figure 2-7 Procedure information for a register-based routine
The register fields use the following constants to encode 680x0 register information:
enum {
/*680x0 registers*/
kRegisterD0 = 0,
kRegisterD1 = 1,
kRegisterD2 = 2,
kRegisterD3 = 3,
kRegisterD4 = 8,
kRegisterD5 = 9,
kRegisterD6 = 10,
kRegisterD7 = 11,
kRegisterA0 = 4,
kRegisterA1 = 5,
kRegisterA2 = 6,
kRegisterA3 = 7,
kRegisterA4 = 12,
kRegisterA5 = 13,
kRegisterA6 = 14,
kCCRegisterCBit = 16,
kCCRegisterVBit = 17,
kCCRegisterZBit = 18,
kCCRegisterNBit = 19,
kCCRegisterXBit = 20
};
Note
The result size should be specified as 0 for results returned
in any of the CCR registers.u
The Mixed Mode Manager also provides constants and macros to specify the procedure information for stack-based routines that take a register-based selector and for stack-
based routines that take a stack-based selector.
Note
See “Procedure Information” beginning on page 2-27 for a complete description of the constants you can use to specify a routine’s procedure information. See “C Language Macros for Defining Procedure Information” on page 2-50 for a complete list of the Mixed Mode Manager macros you can use to create procedure information.u
As noted earlier, there are limits on the number of parameters that a procedure information can describe. Table 2-1 lists the available calling conventions and the maximum number of specifiable parameters and selectors for each convention.
IMPORTANT
The input parameters can be passed in any of the registers D0–D3 and A0–A3; the output parameter can be returned in any register.s
Table 2-1 Limits on the number of specifiable parameters in a procedure information
Calling convention Maximum number of parameters Number of selectors
kPascalStackBased 13 0
kCStackBased 13 0
kRegisterBased 4 input, 1 output 0
kThinkCStackBased 13 0
kD0DispatchedPascalStackBased 12 1
kD0DispatchedCStackBased 12 1
kD1DispatchedPascalStackBased 12 1
kStackDispatchedPascalStackBased 12 1
In general, these limitations should not affect you. There are, however, a very few cases in which the documented behavior of a routine prevents it from being implemented in native PowerPC code. For example, the low-level .ENET driver routines ReadRest
and ReadPacket return information in several registers. As a result, they cannot be implemented natively. (Because these routines are typically called only in code where speed of execution is critical, it’s not likely that you would want to incur the overhead of a mode switch by writing native callbacks to the .ENET driver.)
Using Universal Procedure Pointers
When you call the NewRoutineDescriptor or NewFatRoutineDescriptor function to create a routine descriptor, the Mixed Mode Manager calls the Memory Manager to allocate a nonrelocatable block in the current heap in which to store the new routine descriptor. Eventually, you might want to dispose of the space occupied by the routine descriptor; you can do this by calling the DisposeRoutineDescriptor function.
In general, there are two ways you’ll probably handle this allocation and deallocation. By far the easiest method is to allocate in your application’s heap, at application initialization time, a routine descriptor for each routine whose address you’ll need to pass elsewhere. For example, if your application calls TrackControl with a custom action procedure, you can create a routine descriptor in the application heap when your application starts up, as shown in Listing 2-2.
The routine descriptor pointed to by the global variable myActionProc remains allocated until your application quits, at which time the Process Manager reclaims
all the memory in your application heap.
Note
If you don’t want TrackControl to call an application-defined action procedure, you must pass NULL in place of myActionProc. In that case, you don’t need to call NewRoutineDescriptor.u
The other way to handle routine descriptors is to create them as you need them and then dispose of them as soon as you’re finished with them. This practice would be useful for routines you don’t call very often. Listing 2-3 shows a way to call the ModalDialog function to display a rarely used modal dialog box.
If you decide to allocate and dispose of routine descriptors locally, make sure that you don’t dispose of a routine descriptor before it’s actually used by the Operating System. (This could happen, for instance, if you pass a universal procedure pointer for a comple-
tion routine and then exit the local procedure before the completion routine is called.)
Note
You should call DisposeRoutineDescriptor only to dispose routine descriptors that you created using either NewRoutineDescriptor or NewFatRoutineDescriptor.u
Using Static Routine Descriptors
Instead of allocating space for routine descriptors in your application heap (as described in the previous section), you can also create routine descriptors on the stack or in your global variable space by using macros supplied by the Mixed Mode Manager. Most likely, you’ll create a descriptor on the stack when you need to use a routine descriptor for a very short time. For example, you could use the function defined in Listing 2-4 instead of the one defined in Listing 2-3.
As you can see, the DoAboutBox function defined in Listing 2-4 uses the macro BUILD_ROUTINE_DESCRIPTOR to create a routine descriptor on the stack and then passes the address of that routine descriptor to the ModalDialog procedure. Because the routine descriptor is created on the stack, there is no need to dispose of it before exiting the DoAboutBox function.
You can create a routine descriptor in your application’s global data area by using the BUILD_ROUTINE_DESCRIPTOR macro as follows:
static RoutineDescriptor myRD =
BUILD_ROUTINE_DESCRIPTOR(uppModalFilterProcInfo,
(ProcPtr)MyEventFilter);
This line of code creates a routine descriptor as part of the application global variables. The advantage of this method is that you don’t have to call NewRoutineDescriptor to allocate a routine descriptor in your heap.
The C language macro BUILD_ROUTINE_DESCRIPTOR is defined in Listing 2-5.
You should use the BUILD_ROUTINE_DESCRIPTOR macro only to create a routine descriptor that describes a nondispatched routine
that exists as PowerPC code.s
The Mixed Mode Manager also defines a C language macro that you can use to
create static fat routine descriptors. See the Mixed Mode Manager interface file for
the definition of the BUILD_FAT_ROUTINE_DESCRIPTOR macro.
Executing Resource-Based Code
As you’ve seen earlier in this book (in the section “Executable Resources” on page 1-34), you can create executable resources that contain PowerPC code to serve as accelerated versions of 680x0 code resources. The accelerated resource is simply a PowerPC version of the 680x0 code resource, prefixed with a routine descriptor for the code contained in the resource. The routine descriptor is necessary for the Mixed Mode Manager to know whether it needs to change modes in order to execute the code. The routine descriptor also lets the Mixed Mode Manager know whether it needs to call the Code Fragment Manager to prepare the fragment. Figure 2-8 shows the structure your code-containing resources should have.
Figure 2-8 General structure of an executable code resource
The procDescriptor field of the routine record—contained in the routineRecords field of the routine descriptor—should contain the offset from the beginning of the resource (that is, the beginning of the routine descriptor) to the beginning of the execut-
able code fragment. In addition, the routine flags for the specified code should have the kProcDescriptorIsRelative bit set, indicating that the address is relative, not absolute. If the code contained in the resource is PowerPC code, you should also set the kFragmentNeedsPreparing bit.
It’s also possible to create “fat” code-bearing resources, that is, resources containing both 680x0 and PowerPC versions of some routine. Figure 2-9 shows the general structure of such a resource.
Figure 2-9 General structure of a fat resource
In this case, the routine descriptor contains two routine records in its routineRecords field, one describing the 680x0 code and one describing the PowerPC code. As with any code-bearing resource, the procDescriptor field of each routine record should contain the offset from the beginning of the resource to the beginning of the appropriate code. The flags for both routine records should have the kProcDescriptorIsRelative flag set, and the routine flags for the PowerPC routine record should have the kFragmentNeedsPreparing flag set.
The MPW interface file MixedMode.r provides Rez templates that you can use to create the accelerated resource shown in Figure 2-8 or the fat resource shown in Figure 2-9.
sWARNING
Do not call accelerated resources at interrupt time unless you are certain that the resource has already been loaded into memory, locked, and prepared for execution. If the resource containing the code hasn’t
been prepared, the Code Fragment Manager will attempt to do so,
and thereby allocate memory. (Memory allocation is not allowed at
interrupt time.)s
Mixed Mode Manager Reference
This section describes the constants, data structures, and routines provided by the Mixed Mode Manager. See “Using the Mixed Mode Manager” beginning on page 2-14 for detailed instructions on using these routines.
Constants
This section describes the constants provided by the Mixed Mode Manager. You use these constants to specify routine descriptor flags and a routine’s procedure information. Because the universal interface files define procedure information for the most common callback routines, it’s likely that you won’t need to use the procedure information constants listed here.
Routine Descriptor Flags
The routineDescriptorFlags field of a routine descriptor contains a set of routine descriptor flags that specify attributes of the described routine. You can use constants
to specify the routine descriptor flags. In general, you should use the constant kSelectorsAreNotIndexable when constructing your own routine descriptors; the value kSelectorsAreIndexable is reserved for use by Apple.
enum {
kSelectorsAreNotIndexable = (RDFlagsType)0x00,
kSelectorsAreIndexable = (RDFlagsType)0x01
};
Constant descriptions
kSelectorsAreNotIndexable
For dispatched routines, the recognized routine selectors are
not contiguous.
kSelectorsAreIndexable
For dispatched routines, the recognized routine selectors are contiguous and therefore indexable.
Procedure Information
The Mixed Mode Manager uses a long word of type ProcInfoType to encode a routine’s procedure information, which contains essential information about the calling conventions and other features of a routine. These values specify
n the routine’s calling conventions
n the sizes and locations of the routine’s parameters, if any
n the size and location of the routine’s result, if any
See “Specifying Procedure Information” beginning on page 2-14 for a description of the general structure of a routine’s procedure information. The Mixed Mode Manager provides a number of constants that you can use to specify the procedure information.
The following constants are used to specify the size (in bytes) of a value encoded in a routine’s procedure information.
enum {
/*size codes*/
kNoByteCode = 0,
kOneByteCode = 1,
kTwoByteCode = 2,
kFourByteCode = 3
};
Constant descriptions
kNoByteCode The value occupies no bytes.
kOneByteCode The value occupies 1 byte.
kTwoByteCode The value occupies 2 bytes.
kFourByteCode The value occupies 4 bytes.
The offsets to fields and the widths of the fields within a value of type ProcInfoType are defined by constants:
/*offsets to and widths of procedure information fields*/
#define kCallingConventionPhase 0
#define kCallingConventionWidth 4
#define kResultSizePhase kCallingConventionWidth
#define kResultSizeWidth 2
#define kResultSizeMask 0x30
#define kStackParameterPhase 6
#define kStackParameterWidth 2
#define kRegisterResultLocationPhase \
(kCallingConventionWidth + kResultSizeWidth)
#define kRegisterResultLocationWidth 5
#define kRegisterParameterPhase \
(kCallingConventionWidth + kResultSizeWidth + \
kRegisterResultLocationWidth)
#define kRegisterParameterWidth 5
#define kRegisterParameterWhichPhase 2
#define kRegisterParameterSizePhase 0
#define kDispatchedSelectorSizeWidth 2
#define kDispatchedSelectorSizePhase \
(kCallingConventionWidth + kResultSizeWidth)
#define kDispatchedParameterPhase \
(kCallingConventionWidth + kResultSizeWidth + \
kDispatchedSelectorSizeWidth)
Constant descriptions
kCallingConventionPhase
The offset from the least significant bit in the procedure information to the calling convention information.
kCallingConventionWidth
The number of bits in the procedure information that encode the calling convention information.
kResultSizePhase
The offset from the least significant bit in the procedure information to the function result size information.
kResultSizeWidth
The number of bits in the procedure information that encode the function result size information.
kResultSizeMask
A mask for the bits in the procedure information that encode the function result size information.
kStackParameterPhase
The offset from the least significant bit in the procedure information to the stack parameter information.
kStackParameterWidth
The number of bits in the procedure information that encode the size of a stack-based parameter.
kRegisterResultLocationPhase
The offset from the least significant bit in the procedure information to the result register information.
kRegisterResultLocationWidth
The number of bits in the procedure information that encode which register the result will be stored in.
kRegisterParameterPhase
The offset from the least significant bit in the procedure information to the register parameter information.
kRegisterParameterWidth
The number of bits in the procedure information that encode the information about a register-based parameter.
kRegisterParameterWhichPhase
The offset from the beginning of a register parameter information field to the encoded register.
kRegisterParameterSizePhase
The offset from the beginning of a register parameter information field to the encoded size of the parameter.
kDispatchedSelectorSizeWidth
The number of bits in the procedure information that encode the size of a routine-dispatching selector.
kDispatchedSelectorSizePhase
The offset from the least significant bit in the procedure information to the selector size information of a routine that is dispatched though a selector.
kDispatchedParameterPhase
The offset from the least significant bit in the procedure information to the parameter information of a routine that is dispatched though a selector.
The following constants are used to specify a routine’s calling conventions:
The routine follows normal Pascal calling conventions.
kCStackBased The routine follows the C calling conventions employed by the MPW development environment.
kRegisterBased
The parameters are passed in registers.
kThinkCStackBased
The routine follows the C calling conventions employed by the THINK C software development environment. Arguments are passed on the stack from right to left, and a result is returned in register D0. All arguments occupy an even number of bytes on
the stack. An argument having the size of a char is passed in the high-order byte. You should always provide function prototypes; failure to do so may cause THINK C to generate code that is incompatible with this parameter-passing convention.
kD0DispatchedPascalStackBased
The parameters are passed on the stack according to Pascal conventions, and the routine selector is passed in register D0.
kD0DispatchedCStackBased
The parameters are passed on the stack according to C conventions, and the routine selector is passed in register D0.
kD1DispatchedPascalStackBased
The parameters are passed on the stack according to Pascal conventions, and the routine selector is passed in register D1.
kStackDispatchedPascalStackBased
The routine selector and the parameters are passed on the stack.
kSpecialCase The routine is a special case. You can use the following constants to specify a special case.
The routine follows the calling conventions documented in Inside Macintosh: Text; a rectangle is on the stack and a pointer is in register A3; no result is returned.
kSpecialCaseCaretHook
The routine follows the calling conventions documented in Inside Macintosh: Text; a rectangle is on the stack and a pointer is in register A3; no result is returned.
kSpecialCaseEOLHook
Parameters are passed to the routine in registers A3, A4, and D0, and output is returned in the Z flag of the Status Register. An EOLHook routine has these calling conventions.
kSpecialCaseWidthHook
Parameters are passed to the routine in registers A0, A3, A4, D0, and D1, and output is returned in register D1. A WIDTHHook routine has these calling conventions.
kSpecialCaseNWidthHook
Parameters are passed to the routine in registers A0, A2, A3, A4, D0, and D1, and output is returned in register D1. An nWIDTHHook routine has these calling conventions.
kSpecialCaseTextWidthHook
Parameters are passed to the routine in registers A0, A3, A4, D0, and D1, and output is returned in register D1. A TextWidthHook routine has these calling conventions.
kSpecialCaseDrawHook
Parameters are passed to the routine in registers A0, A3, A4, D0, and D1, and no result is returned. A DRAWHook routine has these calling conventions.
kSpecialCaseHitTestHook
Parameters are passed to the routine in registers A0, A3, A4, D0, D1, and D2, and output is returned in registers D0, D1, and D2. A HITTESTHook routine has these calling conventions.
kSpecialCaseTEFindWord
Parameters are passed to the routine in registers A3, A4, D0, and D2, and output is returned in registers D0 and D1. A TEFindWord hook has these calling conventions.
kSpecialCaseProtocolHandler
Parameters are passed to the routine in registers A0, A1, A2, A3, A4, and in the low-order word of register D1; output is returned in the Z flag of the Status Register. A protocol handler has these calling conventions.
kSpecialCaseSocketListener
Parameters are passed to the routine in registers A0, A1, A2, A3, A4, in the low-order byte of register D0, and in the low-order word of register D1; output is returned in the Z flag of the Status Register. A socket listener has these calling conventions.
kSpecialCaseTERecalc
Parameters are passed to the routine in registers A3 and D7, and output is returned in registers D2, D3, and D4. A TextEdit line-start recalculation routine has these calling conventions.
kSpecialCaseTEDoText
Parameters are passed to the routine in registers A3, D3, D4, and D7, and output is returned in registers A0 and D0. A TextEdit text-display, hit-test, and caret-positioning routine has these calling conventions.
kSpecialCaseGNEFilterProc
Parameters are passed to the routine in registers A1 and D0 and on the stack, and output is returned on the stack. A GetNextEvent filter procedure has these calling conventions.
kSpecialCaseMBarHook
Parameters are passed to the routine on the stack, and output is returned in register D0. A menu bar hook routine has these calling conventions.
For register-based routines, the registers are encoded in the routine’s procedure information using these constants:
enum {
/*680x0 registers*/
kRegisterD0 = 0,
kRegisterD1 = 1,
kRegisterD2 = 2,
kRegisterD3 = 3,
kRegisterD4 = 8,
kRegisterD5 = 9,
kRegisterD6 = 10,
kRegisterD7 = 11,
kRegisterA0 = 4,
kRegisterA1 = 5,
kRegisterA2 = 6,
kRegisterA3 = 7,
kRegisterA4 = 12,
kRegisterA5 = 13,
kRegisterA6 = 14,
kCCRegisterCBit = 16,
kCCRegisterVBit = 17,
kCCRegisterZBit = 18,
kCCRegisterNBit = 19,
kCCRegisterXBit = 20
};
Constant descriptions
kRegisterD0 Register D0.
kRegisterD1 Register D1.
kRegisterD2 Register D2.
kRegisterD3 Register D3.
kRegisterD4 Register D4.
kRegisterD5 Register D5.
kRegisterD6 Register D6.
kRegisterD7 Register D7.
kRegisterA0 Register A0.
kRegisterA1 Register A1.
kRegisterA2 Register A2.
kRegisterA3 Register A3.
kRegisterA4 Register A4.
kRegisterA5 Register A5.
kRegisterA6 Register A6.
kCCRegisterCBit
The C (carry) flag of the Status Register.
kCCRegisterVBit
The V (overflow) flag of the Status Register.
kCCRegisterZBit
The Z (zero) flag of the Status Register.
kCCRegisterNBit
The N (negative) flag of the Status Register.
kCCRegisterXBit
The X (extend) flag of the Status Register.
Routine Flags
The routineFlags field of a routine record contains a set of flags that specify informa-
tion about a routine. You can use constants to specify the desired routine flags. Currently, only 5 of the 16 bits in a routine flags word are defined. You should set all the other
The address of the routine’s entry point specified in the procDescriptor field of a routine record is an absolute address.
kProcDescriptorIsRelative
The address of the routine’s entry point specified in the procDescriptor field of a routine record is relative to the beginning of the routine descriptor. If the code is contained in a resource and its absolute location is not known until run time, you should set this flag.
enum {
kFragmentIsPrepared = (RoutineFlagsType)0x00,
kFragmentNeedsPreparing = (RoutineFlagsType)0x02
};
Constant descriptions
kFragmentIsPrepared
The fragment containing the code to be executed is already loaded into memory and prepared by the Code Fragment Manager.
kFragmentNeedsPreparing
The fragment containing the code to be executed needs to be loaded into memory and prepared by the Code Fragment Manager. If this flag is set, the kPowerPCISA and kProcDescriptorIsRelative flags should also be set.
enum {
kUseCurrentISA = (RoutineFlagsType)0x00,
kUseNativeISA = (RoutineFlagsType)0x04
};
Constant descriptions
kUseCurrentISA If possible, use the current instruction set architecture when executing a routine.
kUseNativeISA Use the native instruction set architecture when executing a routine.
enum {
kPassSelector = (RoutineFlagsType)0x00,
kDontPassSelector = (RoutineFlagsType)0x08
};
Constant descriptions
kPassSelector Pass the routine selector to the target routine as a parameter.
kDontPassSelector
Do not pass the routine selector to the target routine as a parameter. You should not use this flag for 680x0 routines.
enum {
kRoutineIsNotDispatchedDefaultRoutine
= (RoutineFlagsType)0x00,
kRoutineIsDispatchedDefaultRoutine
= (RoutineFlagsType)0x10
};
Constant descriptions
kRoutineIsNotDispatchedDefaultRoutine
This routine is not the default routine for a set of routines that is dispatched using a routine selector.
kRoutineIsDispatchedDefaultRoutine
This routine is the default routine for a set of routines that is dispatched using a routine selector. If a set of routines is dispatched using a routine selector and the routine corresponding to a specified selector cannot be found, this default routine is called. This routine must be able to accept the same procedure information for all routines. If possible, it is passed the procedure information passed in a call to CallUniversalProc.
IMPORTANT
In general, you should use the constants kPassSelector and kRoutineIsNotDispatchedDefaultRoutine. The constants kDontPassSelector and kRoutineIsDispatchedDefaultRoutine are reserved for use with selector-based system software routines.s
Instruction Set Architectures
The ISA field of a routine record contains a flag that specifies the instruction set architecture of a routine. You can use constants to specify the instruction set architecture.
enum {
kM68kISA = (ISAType)0, /*MC680x0 architecture*/
kPowerPCISA = (ISAType)1 /*PowerPC architecture*/
};
Constant descriptions
kM68kISA The routine consists of 680x0 code.
kPowerPCISA The routine consists of PowerPC code.
Data Structures
This section describes the two data structures provided by the Mixed Mode Manager:
n the routine record, which contains information about a routine’s calling conventions, the sizes and locations of its parameters, and its location in memory
n the routine descriptor, which provides a generalization of procedure pointers (variables of type ProcPtr) common in the 680x0 environment
Routine Records
A routine record is a data structure that contains information about a particular routine. The routine descriptor specifies, among other things, the instruction set architecture
of the routine, the number and size of the routine’s parameters, the routine’s calling conventions, and the routine’s location in memory. At least one routine record is contained in the routineRecords field of a routine descriptor. A routine record is defined by the RoutineRecord data type.
struct RoutineRecord {
ProcInfoType procInfo; /*calling conventions*/
unsigned char reserved1; /*reserved*/
ISAType ISA; /*instruction set architecture*/
RoutineFlagsType routineFlags; /*flags for each routine*/
procInfo A value of type ProcInfoType that encodes essential information about the routine’s calling conventions and parameters. See “Procedure Information” beginning on page 2-27 for a complete list of the constants you can use to set this field.
reserved1 Reserved. This field must be 0.
ISA The instruction set architecture of the routine. See “Instruction Set Architectures” beginning on page 2-35 for a complete listing of the constants you can use to set this field.
routineFlags A value of type RoutineFlagsType that contains a set of flags describing the routine. See “Routine Flags” beginning on page 2-34 for a complete listing of the constants you can use to set this field.
procDescriptor
A pointer to the routine’s code. If the routine consists of 680x0
code and the kProcDescriptorIsAbsolute flag is set in the routineFlags field, then this field contains the address of the routine’s entry point. If the routine consists of 680x0 code and the kProcDescriptorIsRelative flag is set, then this field contains the offset from the beginning of the routine descriptor to the routine’s entry point. If the routine consists of PowerPC code,
the kFragmentIsPrepared flag is set, and the kProcDescriptorIsAbsolute flag is set, then this field contains the address of the routine’s transition vector. If the routine consists of PowerPC code, the kFragmentNeedsPreparing flag is set,
and the kProcDescriptorIsRelative flag is set, then this field contains the offset from the beginning of the routine descriptor to the routine’s entry point.
reserved2 Reserved. This field must be 0.
selector Reserved. This field must be 0. For routines that are dispatched, this field contains the routine selector.
Routine Descriptors
A routine descriptor is a data structure used by the Mixed Mode Manager to execute a routine. The external interface to a routine descriptor is through a universal procedure pointer, of type UniversalProcPtr, which is defined as a procedure pointer (if the code is 680x0 code) or as a pointer to a routine descriptor (if the code is PowerPC code). A routine descriptor is defined by the RoutineDescriptor data type.
struct RoutineDescriptor {
unsigned short goMixedModeTrap; /*mixed-mode A-trap*/
An A-line instruction that is used privately by the Mixed Mode Manager. When the emulator encounters this instruction, it transfers control to the Mixed Mode Manager. This field contains the value $AAFE.
version The version number of the RoutineDescriptor data type. The current version number is defined by the constant kRoutineDescriptorVersion:
enum {kRoutineDescriptorVersion = 7};
routineDescriptorFlags
A set of routine descriptor flags. Currently, all the bits in this field should be set to 0, unless you are specifying a routine descriptor for a dispatched routine. See “Routine Descriptor Flags” on page 2-27 for a complete description of these flags.
reserved1 Reserved. This field must initially be 0.
reserved2 Reserved. This field must be 0.
selectorInfo Reserved. This field must be 0.
routineCount The index of the final routine record in the following array, routineRecords. Because the routineRecords array is zero-
based, this field does not contain an actual count of the routine records contained in that array. Often, you’ll use a routine descriptor to describe a single procedure, in which case this field should contain the value 0. You can, however, construct a routine descriptor that contains pointers to both 680x0 and PowerPC code (known as a “fat” routine descriptor). In that case, this field should contain the value 1.
routineRecords
An array of routine records for the routines described by this routine descriptor. See “Routine Records” on page 2-36 for the structure of a routine record. This array is zero-based.
IMPORTANT
Your application (or other software) should never attempt to guide its execution by inspecting the value in the ISA field of a routine record and jumping to the address in the procDescriptor field.s
Mixed Mode Manager Routines
This section describes the routines provided by the Mixed Mode Manager. You can use these routines to
n create and dispose of routine descriptors
n execute routines described by routine descriptors
In general, you need to call these routines only from PowerPC code. To maintain a single source code base for your software, however, you can call Mixed Mode Manager routines from 680x0 code, as long as you set the USESROUTINEDESCRIPTORS compiler flag to false (its default setting). To compile code for the PowerPC environment, you should set the USESROUTINEDESCRIPTORS flag to true.
See “Using the Mixed Mode Manager” beginning on page 2-14 for detailed instructions on using these routines.
Creating and Disposing of Routine Descriptors
The Mixed Mode Manager provides routines that you can use to create and dispose of routine descriptors. In general, you need to create routine descriptors only for routines whose addresses are exported to the system software (for example, a completion procedure). You don’t need to create a routine descriptor for a routine that is called by code of the same type.
NewRoutineDescriptor
You can call the NewRoutineDescriptor function to create a new routine descriptor.
pascal UniversalProcPtr NewRoutineDescriptor
(ProcPtr theProc, ProcInfoType theProcInfo,
ISAType theISA);
theProc The address of the routine.
theProcInfo
The procedure information to be associated with the routine.
theISA The instruction set architecture of the routine being described.
DESCRIPTION
The NewRoutineDescriptor function creates a new routine descriptor and returns a pointer (of type UniversalProcPtr) to it. If the value of the theProc parameter is NULL, NewRoutineDescriptor returns the value NULL.
The memory occupied by the new routine descriptor is allocated in the current heap. If you want the memory to be allocated in some other heap, you’ll need to set the current heap to that heap and then restore the current heap before exiting.
SPECIAL CONSIDERATIONS
The NewRoutineDescriptor function allocates memory; you should not call it at interrupt time or from any code that might be executed when memory is low. In addition, the block of memory allocated by NewRoutineDescriptor is nonrelocatable. To help minimize heap fragmentation, you should try to allocate any routine descriptors you will need early in your application’s execution.
When the USESROUTINEDESCRIPTORS compile flag is false, the NewRoutineDescriptor function simply returns the address passed in
the theProc parameter and does not allocate memory for a routine descriptor.
SEE ALSO
See “Using Universal Procedure Pointers” beginning on page 2-21 for a more complete description of when and how to create routine descriptors. See “Specifying Procedure Information” beginning on page 2-14 for information on creating procedure information.
NewFatRoutineDescriptor
You can call the NewFatRoutineDescriptor function to create a new fat routine descriptor.
pascal UniversalProcPtr NewFatRoutineDescriptor
(ProcPtr theM68kProc, ProcPtr thePowerPCProc,
ProcInfoType theProcInfo);
theM68kProc
The address of a 680x0 routine.
thePowerPCProc
The address of a PowerPC routine.
theProcInfo
The procedure information to be associated with the routine.
DESCRIPTION
The NewFatRoutineDescriptor function creates a new fat routine descriptor and returns a pointer (of type UniversalProcPtr) to it. The routine descriptor contains routine records for both 680x0 and PowerPC versions of a routine. If the value of either the theM68kProc parameter or the thePowerPCProc parameter is NULL, NewFatRoutineDescriptor returns the value NULL.
The memory occupied by the new routine descriptor is allocated in the current heap. If you want the memory to be allocated in some other heap, you’ll need to set the current heap to that heap and then restore the original heap before exiting.
SPECIAL CONSIDERATIONS
The NewFatRoutineDescriptor function allocates memory; you should not call it at interrupt time or from any code that might be executed when memory is low. In addition, the block of memory allocated by NewFatRoutineDescriptor is nonrelocatable. To help minimize heap fragmentation, you should try to allocate any routine descriptors you will need early in your application’s execution.
When the USESROUTINEDESCRIPTORS compile flag is false, the NewFatRoutineDescriptor function is undefined.
SEE ALSO
See “Using Universal Procedure Pointers” beginning on page 2-21 for a more complete description of when and how to create routine descriptors. See “Specifying Procedure Information” beginning on page 2-14 for information on creating procedure information.
DisposeRoutineDescriptor
You can call the DisposeRoutineDescriptor function to dispose of a routine descriptor.
pascal void DisposeRoutineDescriptor
(UniversalProcPtr theProcPtr);
theProcPtr
A universal procedure pointer.
DESCRIPTION
The DisposeRoutineDescriptor function disposes of the routine descriptor pointed to by the theProcPtr parameter. You should call this function to release any memory allocated by a previous call to NewRoutineDescriptor.
The Operating System automatically disposes of any remaining routine descriptors held by your application when ExitToShell is executed on its behalf. As a result, you don’t need to explicitly dispose of any routine descriptors that you have allocated in your application heap.
SPECIAL CONSIDERATIONS
Be careful not to dispose of a routine descriptor that is still in use by the Operating System. Code that installs completion routines or other routines called asynchronously may complete before the completion routine is actually called.
When the USESROUTINEDESCRIPTORS compile flag is false, the DisposeRoutineDescriptor function does nothing.
Calling Routines via Universal Procedure Pointers
The Mixed Mode Manager provides a function that allows you to execute the routine associated with a universal procedure pointer. It also provides a function that allows you to call the routine associated with a universal procedure pointer, following Operating System register saving and restoring conventions.
CallUniversalProc
You can use the CallUniversalProc function to call the routine associated with a universal procedure pointer.
long CallUniversalProc (UniversalProcPtr theProcPtr,
ProcInfoType theProcInfo, ...);
theProcPtr
A universal procedure pointer.
theProcInfo
The procedure information associated with the routine specified by the theProcPtr parameter.
DESCRIPTION
The CallUniversalProc function executes the routine associated with the specified universal procedure pointer. You pass CallUniversalProc a universal procedure pointer (which may be either a 680x0 procedure pointer or the address of the routine descriptor), a set of procedure information, and a variable number of parameters that are passed to the routine. CallUniversalProc returns a result of type long that contains the result (if any) returned by the called routine.
SPECIAL CONSIDERATIONS
If the universal procedure pointer passed to CallUniversalProc is the address
of the routine descriptor, that routine descriptor must already exist before you call CallUniversalProc. If you pass the address of an invalid routine descriptor to CallUniversalProc, a system error will occur.
CallOSTrapUniversalProc
You can call the CallOSTrapUniversalProc function to call the routine associated with a universal procedure pointer, following Operating System register saving and restoring conventions. You’re likely to need to use this function only if you need to patch an Operating System trap.
long CallOSTrapUniversalProc (UniversalProcPtr theProcPtr,
ProcInfoType theProcInfo, ...);
theProcPtr
A universal procedure pointer.
theProcInfo
The procedure information associated with the routine specified by the theProcPtr parameter.
DESCRIPTION
The CallOSTrapUniversalProc function executes the routine associated with the specified universal procedure pointer, following standard conventions for executing Operating System traps. Registers A1, A2, D1, and D2 are saved before the routine is executed and restored after its completion; in addition, register A0 is saved and restored, depending on the setting of the appropriate flag bit in the trap word. The trap number
is put into register D1; you should make certain to record that fact in any procedure information you build yourself.
You pass CallOSTrapUniversalProc a universal procedure pointer (which may be either a 680x0 procedure pointer or the address of a routine descriptor), a set of procedure information, and a variable number of parameters that are passed to the routine. CallOSTrapUniversalProc returns a result of type long that contains the result (if any) returned by the called routine.
SPECIAL CONSIDERATIONS
If the universal procedure pointer passed to CallOSTrapUniversalProc is the address of the routine descriptor, that routine descriptor must already exist before you call CallOSTrapUniversalProc. If you pass the address of an invalid routine descriptor
to CallOSTrapUniversalProc, a system error will occur.
The CallOSTrapUniversalProc function is defined only for register-based Operating System traps. Make sure that the procedure information specified in the theProcInfo parameter correctly specifies the calling conventions of the trap. In particular, do not specify either C or Pascal calling conventions.
Determining Instruction Set Architectures
The Mixed Mode Manager contains a function that you can use to determine the current instruction set architecture.
GetCurrentISA
You can use the GetCurrentISA function to get the current instruction set architecture.
ISAType GetCurrentISA (void);
DESCRIPTION
The GetCurrentISA function returns the current instruction set architecture. See “Instruction Set Architectures” on page 2-35 for a list of the values GetCurrentISA
can return.
SPECIAL CONSIDERATIONS
Currently, the GetCurrentISA function is defined as a compiler macro.
This chapter describes the Code Fragment Manager, the part of the Macintosh system software that loads fragments into memory and prepares them for execution. A fragment can be an application, an import library, a system extension, or any other block of executable code and its associated data.
The Code Fragment Manager is intended to operate transparently to most applications and other software. You need to use the Code Fragment Manager explicitly only if
n you need to load code modules dynamically during the execution of your application or other software
n you want to unload code modules before the termination of your application
n you want to obtain information about the symbols exported by a fragment
For example, if your application supports dynamic loading of tools, filters, or other software modules contained in fragments, you’ll need to use the Code Fragment Manager to load and prepare them for execution.
This chapter also describes the format of the code fragment resource, which defines information about a fragment. You need to create a code fragment resource (a resource
of type 'cfrg') for each application or import library you create. For information on doing this, see “Creating a Code Fragment Resource” on page 3-12.
To use this chapter, you should already be generally familiar with the Macintosh Operating System. See the books Inside Macintosh: Processes and Inside Macintosh: Memory for information about the run-time architecture of the 680x0 environment. You also need to be familiar with the run-time architecture of PowerPC processor-based Macintosh computers, as explained in the chapter “Introduction to PowerPC System Software.” That chapter describes the general nature and structure of fragments.
This chapter begins by describing the capabilities of the Code Fragment Manager. Then it describes how the Code Fragment Manager searches for the appropriate versions of import libraries. In general, you need to know these details about searching and version checking only if you are creating updated versions of an existing import library. The section “Using the Code Fragment Manager” beginning on page 3-10 provides code samples illustrating how to use some of the routines provided by the Code Fragment Manager. The section “Code Fragment Manager Reference” beginning on page 3-15 is a complete reference to the Code Fragment Manager.
About the Code Fragment Manager
The Code Fragment Manager is the Operating System loader for executable code and data that are contained in fragments. Its operations are loosely analogous to those of the Segment Manager in previous versions of the Macintosh system software. The Code Fragment Manager, however, provides a much richer set of services than the Segment Manager, including
n loading and preparation of fragments for execution
n automatic resolution of imported symbols by locating and loading import libraries used by a fragment
n automatic execution of a fragment’s initialization and termination routines
n support for updated versions of import libraries
The following sections describe how fragments are structured, how the Code Fragment Manager searches fragments for unresolved symbols, and how it manages different versions of import libraries.
Fragments
The Code Fragment Manager operates primarily on fragments. A fragment is a block of executable code and its associated data. Fragments can be loosely differentiated into three categories, based on how they are used:
n applications
n import libraries
n extensions
Fragments contain symbols, some or all of which may be referenced by code or data in other fragments; these kinds of symbols are called exported symbols (or, for brevity, exports). An import library is a fragment that consists primarily of exported symbols and their associated code and data. Other kinds of fragments can contain references to the exported symbols of an import library; these references are called imported symbols (or, for brevity, imports).
During the linking phase of building a fragment, the linker creates an import for each external symbol that is resolved to an export from some import library. The code or data referenced by that import is not copied into the fragment. Instead, as part of the process of loading the fragment into memory and preparing it for execution, the Code Fragment Manager replaces the imported symbol with the address of the exported code or data.
Note
Both code and data may be exported by name. However, routines are usually exported indirectly, via a transition vector to the routine. A routine’s transition vector is stored in the fragment’s data area. See
“The Table of Contents” on page 1-26 for more details.u
A fragment is stored in a container, which can be any logically contiguous object acces-
sible by the Operating System. For example, the executable code and global variables
of a PowerPC application are typically stored in a fragment in the application’s data fork. The Macintosh ROM is itself a container for the import library that exports
the Macintosh system software and for several other import libraries. Application extensions, such as dynamically loadable filters or other code modules, can be stored in resources in the application’s resource fork. It’s better, however, to use the data fork of some file as the container of an application extension fragment. The extension can be put into the application’s data fork (either before or after the application’s code fragment) or into the data fork of some other file.
Note
Note
A single data fork can contain multiple containers. The 'cfrg' resource in the file’s resource fork allows the Operating System to find each individual container in a data fork.u
The Code Fragment Manager is responsible for loading fragments (by calling the Code Fragment Loader) and preparing them for execution. It resolves the imported symbols
in a fragment, loading and preparing any additional fragments whose exports are referenced by that fragment. Loading a given fragment, such as an application, usually involves loading and preparing additional fragments.
An import library can have its exported symbols imported by any number of other frag-
ments. When the Code Fragment Manager resolves the imports in a particular fragment, it establishes a connection to each individual fragment whose code or data that fragment references. In general, the connections are transparent to the importing fragment. If you call the Code Fragment Manager directly, however, it returns a connection ID to you that uniquely identifies the connection. You can use the connection ID to perform various actions on the exporting fragment (for example, to break the connection and unload the fragment or to get information about its exported symbols).
Note
There is no practical limit on the size of a fragment.u
Import Library Searching
When searching for an import library to find code or data that is imported by some other fragment, the Code Fragment Manager follows a standard search path. It looks in various files and folders in a specific order until it finds an import library that exports the code or data imported by the fragment being loaded. Once the Code Fragment Manager finds a library that it deems compatible with the fragment it’s loading, it stops searching and resolves imports in the fragment to code or data in that library. In general, the exact order in which the Code Fragment Manager searches for import libraries is transparent to your software. However, you might need the information in this section to ensure that a particular import library is found before some other import library, which might also be compatible with your fragment.
Note
See the next section, “Version Checking” beginning on page 3-7, for information on how the Code Fragment Manager determines whether some import library is compatible with a fragment.u
When loading and preparing an application that imports code or data from an import library, the Code Fragment Manager searches first in the application file itself, by looking for import libraries indicated in the application’s 'cfrg' resource. Typically, any import libraries contained in your application are located in your application’s data fork, either before or after the container that holds your application’s code and data. Less commonly, you can put an import library into a resource in your application’s resource fork. The 'cfrg' resource specifies the location of any import libraries that you’ve included with your application, whether in the data or the resource fork.
If an import library used by your application is not found in the application file itself, the Code Fragment Manager next searches in any directory designated as the application’s library directory, a directory used by the application to store import libraries or aliases to import libraries. You specify a library directory by including in the appropriate field of your 'cfrg' resource the ID of an alias resource that picks out the library directory. See “The Code Fragment Resource” beginning on page 3-28 for details.
The Code Fragment Manager searches a directory by looking for files of type 'shlb' that contain a resource of type 'cfrg'. The 'cfrg' resource identifies the logical name of the import library, which is needed to match the library’s name generated at link time. There can be more than one logical name listed in a single 'cfrg' resource. This might happen if there are multiple import libraries contained in the data fork of a single 'shlb' file. This might also happen if a single import library or application is to be identified by more than one name. Within a directory, the Code Fragment Manager also looks for aliases to files of type 'shlb' and resolves them to their targets. The alias file must itself be of type 'shlb'.
If no suitable import library has been found yet, the Code Fragment Manager searches next in the directory that contains the application. If any import libraries—whether located in the application’s directory or targeted by an alias in the application’s directory—are determined to be compatible with the fragment whose imports are being resolved, the Code Fragment Manager chooses the most compatible library and stops searching.
IMPORTANT
The Code Fragment Manager looks only in the top level of the application’s directory, not in any subdirectories contained in it.s
If no suitable import library has been found yet, the Code Fragment Manager searches next in the Extensions folder in the System Folder and in all the subdirectories of the Extensions folder, including any directories that are targets of directory aliases in
the Extensions folder. Once again, both files of type 'shlb' and targets of aliases of
type 'shlb' are candidates for compatibility checking. This scheme allows you to store your import libraries in a vendor-specific location in the Extensions folder.
If the Code Fragment Manager still hasn’t found a compatible import library that exports the imported symbols in the fragment it’s trying to prepare, it continues by looking in a ROM registry, which keeps track of all import libraries that are stored in the ROM of a Macintosh computer. The Code Fragment Manager registers all ROM-based import libraries in this registry at system startup time.
The final stage of the search path is a file and directory registry that it maintains internally. This registry is a list of files and directories that, for various reasons, cannot be put into the normal search path followed by the Code Fragment Manager or would not be recognized as import libraries even if they were in that path. For example, to be registered automatically by the Component Manager, a component must be stored
in a file of type 'thng'. To inform the Code Fragment Manager that the file also
contains one or more import libraries in its data fork, it can be registered in the file and directory registry.
Note
The Code Fragment Manager routine to register a file
or directory is currently private.u
If your application or other software loads a fragment explicitly from disk by calling the GetDiskFragment routine, the Code Fragment Manager first looks for any needed import libraries in the load directory, the directory that contains the fragment being loaded. (This directory is the one specified in the fileSpec parameter you pass to GetDiskFragment.) If no suitable import library is found there, the search continues along the path followed when loading and preparing an application. However, the Code Fragment Manager looks in the load directory first only if it is different from the application’s directory. Otherwise, the load directory is searched in its normal sequence, after the application file itself and the library directory.
In summary, the Code Fragment Manager looks in the following places when searching for an import library to resolve one or more imports in a fragment being loaded:
1. The load directory (the directory containing the fragment being loaded). The load directory, however, is searched only when a fragment is loaded in response to a call
to GetDiskFragment or GetSharedLibrary, and only when it’s different from the application’s directory.
2. The application file, if the application’s 'cfrg' resource indicates that the application file contains import libraries. The application fragment is implicitly treated here as an import library.
3. The application’s library directory (as specified in the application’s 'cfrg' resource).
4. The application’s directory. Only the top level of this directory is searched.
5. The Extensions folder in the System Folder. The Extensions folder and all directories in the Extensions folder are searched.
6. The ROM registry maintained internally by the Code Fragment Manager.
7. The file and directory registry maintained internally by the Code Fragment Manager.
At any stage, the Code Fragment Manager selects the one import library of all those available to it that best satisfies its compatibility version checking. If an import library meets the relevant criteria, the library search stops. Otherwise, the search continues to the next stage. If the final stage (the file and directory registry) is reached and no suitable library can be found, the Code Fragment Manager gives up and does not load the original fragment.
Version Checking
One of the principal benefits of import libraries, aside from their ability to reduce the size of applications and other fragments, is the ease with which a library developer can make improvements in portions of the import library without requiring developers to modify or rebuild any applications that use the import library. The library developer needs only to ensure that the updated version is compatible with the version expected by the applications using the library. In general, this means that the external program-
ming interface provided by the import library remains unchanged throughout changes in the underlying implementation.
The Code Fragment Manager provides a simple but powerful version-checking scheme intended to prevent incompatibilities between import libraries and the fragments that use them. This checking is always performed automatically as part of the normal fragment loading and preparation process. In general, your application does not need to concern itself with checking the version of an import library whose code or data it uses.
To take a simple example, suppose that an application uses a single import library. When the application is created, it is linked with some version of that library. Unresolved external symbols in the application are resolved, by the linker, to exported code or data in the import library. The version of the import library used at link time is called the definition version of the library (because it supplies the definitions of exported symbols, not the actual implementation of routines and initialization of variables).
When the application is loaded and prepared for execution, it must be connected to a version of that import library. The version of the import library used at load time is called the implementation version of the library (because it supplies the implementa-
tions of routines and initializations of variables exported by the library). The essential requirement is that the implementation version of an import library used at run time be compatible with the definition version used at link time. The two versions do not need to be identical, but they must satisfy the same programming interface. (The implementation can be a superset of the definition library.)
To allow the Code Fragment Manager to check the implementation version of an import library against the definition version used when linking the application, the linker copies version information from the definition library into the application. When the application is launched, the version information in the application is compared with the version information stored in the implementation library. If the version of the import library is identical to that expected by the application, the library and the application are deemed compatible. If, however, the two versions are not identical, the Code Fragment Manager inspects additional information in whichever of the two fragments (the application and the import library) is the newer fragment. The idea is to allow the newer fragment to decide whether it is compatible with the older fragment.
Every import library contains three version numbers: the current version number, the oldest supported definition version number, and the oldest supported implementation version number. The two latter version numbers are included to provide a way for the Code Fragment Manager to determine whether a given definition version is compatible with a given implementation version, if the current versions of the library and the definition version used to link the application are not identical.
IMPORTANT
The current version number must always be greater than or equal to both the oldest supported definition version number and the oldest supported implementation version number.s
The linker copies into the application both the current version number of the definition library and the oldest supported implementation version number. When the application is launched, the Code Fragment Manager checks those numbers with the version numbers in the implementation libraries according to the algorithm shown in Listing 3-1.
Listing 3-1 Pseudocode for the version-checking algorithm
if (Definition.Current == Implementation.Current)
return(kLibAndAppAreCompatible);
else if (Definition.Current > Implementation.Current)
/*definition version is newer than implementation version*/
if (Definition.OldestImp <= Implementation.Current)
return(kImplAndDefAreCompatible);
else
return(kImplIsTooOld);
else
/*definition version is older than implementation version*/
if (Implementation.OldestDef <= Definition.Current)
return(kImplAndDefAreCompatible);
else
return(kDefIsTooOld);
If the current version number copied into the application from the definition library at link time is the same as the current version number of the candidate version of the implementation import library, then the Code Fragment Manager accepts that version of the implementation import library and continues with the loading and preparation of the application. Otherwise, the Code Fragment Manager determines which of the two fragments is newer and then applies a further check.
If the current version number copied into the application from the definition library
at link time is greater than the current version number of the candidate version of
the implementation import library, the Code Fragment Manager compares the oldest supported implementation version number in the application with the current version number of the implementation library. If the definition library’s oldest supported implementation version number is less than or equal to the library’s current version number, the application and library are deemed compatible. Otherwise, the library is too old for the application.
If the current version number copied into the application from the definition library at link time is less than the current version number of the most recent version of the implementation import library, the Code Fragment Manager compares the oldest supported definition library version number (stored in the implementation library) with the current definition library version number (stored in the application). If the oldest supported definition library version number is less than or equal to the application’s current version number, the application and library are deemed compatible. Otherwise, the application is too old for the library.
Note
Note
In general, of course, the Code Fragment Manager checks the compatibility of a fragment being loaded and all of the import
libraries from which it imports code and data.u
The version numbers in both the definition and implementation versions of an import library should have the same format as the first 4 bytes of a version resource (that is,
a resource of type 'vers'). See the chapter “Finder Interface” in Inside Macintosh: Macintosh Toolbox Essentials for complete information on version resources. When comparing version numbers, however, the Code Fragment Manager treats those 4 bytes simply as an unsigned long quantity. As a result, the value 0x00000000 is interpreted as
a valid version number.
Using the Code Fragment Manager
The Code Fragment Manager provides routines that you can use to explicitly load code fragments and to get information about symbols exported by a particular fragment. This section illustrates how to use those routines.
IMPORTANT
In general, the Code Fragment Manager automatically loads all import libraries required by your application at the time your application is launched. You need to use the routines described in this section only if your application supports dynamically loaded application tools, filters, or other code modules.s
This section also describes how to create a code fragment resource. Every application and import library must have a code fragment resource to describe basic information about the application or import library.
Loading Code Fragments
You can use the Code Fragment Manager to load fragments from the containers in which they are stored. You need to do this only for code fragments that are dynamically added to your application’s context during execution. This might happen, for instance, if your application supports dynamically loadable filters or tools.
The executable code you want to bind to your application context can be stored in any kind of container. If the container is an import library (a file of type 'shlb'), you can use the Code Fragment Manager’s GetSharedLibrary function. If the container is a disk file, you call the GetDiskFragment function. If the container is a resource, you need to load the resource into memory (using normal Resource Manager routines)
and then call the GetMemFragment function. See “Loading Fragments” beginning on page 3-19 for complete details on each of these functions.
Listing 3-2 and Listing 3-3 illustrate how to load application-specific tools into
memory using the Code Fragment Manager. Listing 3-2 shows how to load a resource-based fragment.
As you can see, Listing 3-2 loads the resource into memory by calling the Resource Manager function GetResource and locks it by calling the Memory Manager procedure HLock. Then it calls GetMemFragment to prepare the fragment. The first parameter passed to GetMemFragment specifies the address in memory of the fragment. Because GetResource returns a handle to the resource data, Listing 3-2 dereferences the handle to obtain a pointer to the resource data. To avoid dangling pointers, you need to lock the block of memory before calling GetMemFragment. The constant kLoadNewCopy passed as the fourth parameter requests that the Code Fragment Manager allocate a new copy of the fragment’s global data section.
Listing 3-3 shows how to load a disk-based fragment.
All import libraries and other fragments that are loaded on behalf of your application (either as part of its normal startup or programmatically by your application) are unloaded by the Process Manager at application termination; therefore, a library can be loaded and does not have to be unloaded by the application before it terminates.
Creating a Code Fragment Resource
You need to create a code fragment resource (a resource of type 'cfrg') for each native application or import library you create. This resource identifies the instruction set architecture, location, size, and logical name of the application or import library, as well as version information for import libraries.
In PowerPC or fat applications, the code fragment resource is read by the Process Manager at application launch time. The Process Manager needs to know whether the application contains PowerPC code and, if so, where that code is located. If the Process Manager cannot find a 'cfrg' resource in the application’s resource fork, it assumes that the application is a 680x0 application, where the executable code is contained within 'CODE' resources in the application’s resource fork.
IMPORTANT
A code fragment resource must have resource ID 0.s
For an application, the code fragment resource typically indicates that the application’s executable code fragment begins at offset 0 within the application’s data fork and extends for the entire length of the data fork. Listing 3-4 shows the Rez input for a typical application’s code fragment resource.
Listing 3-4 The Rez input for a typical application’s 'cfrg' resource
#include "CodeFragmentTypes.r"
resource 'cfrg' (0) {
{
kPowerPC, /*instruction set architecture*/
kFullLib, /*no update level for apps*/
kNoVersionNum, /*no current version number*/
kNoVersionNum, /*no oldest def'n version number*/
kDefaultStackSize, /*use default stack size*/
kNoAppSubFolder, /*no library directory*/
kIsApp, /*fragment is an application*/
kOnDiskFlat, /*fragment is on disk*/
kZeroOffset, /*fragment starts at fork start*/
kWholeFork, /*fragment occupies entire fork*/
"SurfWriter" /*name of the application*/
}
};
Note
Note
See “The Code Fragment Resource” on page 3-28 for complete information about the structure of a code fragment resource.u
For import libraries, the code fragment resource is read by the Code Fragment Manager as part of the process of searching for symbols imported by some fragment that is currently being loaded and prepared for execution. (See the section “Import Library Searching” on page 3-5 for details on how the Code Fragment Manager searches for import libraries.) The information in the 'cfrg' resource is also used to ensure that the Code Fragment Manager finds an implementation version of an import library that is compatible with the definition version used to link the fragment being loaded and prepared for execution. Listing 3-5 shows the Rez input for a typical code fragment resource for an import library.
Listing 3-5 The Rez input for a typical import library’s 'cfrg' resource
#define kOldDefVers 0x01008000 /*version 1.0*/
#define kCurrVers 0x02008000 /*version 2.0*/
#include "CodeFragmentTypes.r"
resource 'cfrg' (0) {
{
kPowerPC, /*instruction set architecture*/
kFullLib, /*base library*/
kCurrVers, /*current version number*/
kOldDefVers, /*oldest definition version number*/
kDefaultStackSize, /*ignored for import library*/
kNoAppSubFolder, /*ignored for import library*/
kIsLib, /*fragment is a library*/
kOnDiskFlat, /*fragment is on disk*/
kZeroOffset, /*fragment starts at fork start*/
kWholeFork, /*fragment occupies entire fork*/
"SurfTools" /*name of the library*/
}
};
An import library’s code fragment resource also specifies the logical name of the import library. This is the name used by the Code Fragment Manager to resolve imports in some other fragment. The logical name can be different from the name of the file containing the import library.
Note that code fragment resources are required only for fragments that are either applications or import libraries. If you need similar version-checking or name-binding capabilities for fragments that are application extensions, you will need to provide your own code to do this.
Getting Information About Exported Symbols
In cases in which you load a fragment programmatically (that is, by calling Code Fragment Manager routines), you can get information about the symbols exported
by that fragment by calling the CountSymbols and GetIndSymbol functions.
The CountSymbols function returns the total number of symbols exported by a fragment. CountSymbols takes as one of its parameters a connection ID; accordingly, you must already have established a connection to a fragment before you can determine how many symbols it exports.
Given an index ranging from 1 to the total number of symbols in a fragment, the GetIndSymbol function returns the name, address, and class of a symbol in that fragment. You can use CountSymbols in combination with GetIndSymbol to get information about all the symbols in a fragment. For example, the code in Listing 3-6 prints the names of all the symbols in a particular fragment.
Listing 3-6 Finding symbol names
void MyGetSymbolNames (ConnectionID myConnID);
{
long myIndex;
long myCount; /*number of exported symbols in fragment*/
OSErr myErr;
Str255 myName; /*symbol name*/
Ptr myAddr; /*symbol address*/
SymClass myClass; /*symbol class*/
myErr = CountSymbols(myConnID, &myCount);
if (!myErr)
for (myIndex = 1; myIndex <= myCount; myIndex++)
{
myErr = GetIndSymbol(myConnID, myIndex, myName,
&myAddr, &myClass);
if (!myErr)
printf("%P", myName);
}
}
If you already know the name of a particular symbol whose address and class you want to determine, you can use the FindSymbol function. See page 3-24 for details on calling FindSymbol.
Code Fragment Manager Reference
This section describes the data structures and routines provided by the Code Fragment Manager. See “Using the Code Fragment Manager” beginning on page 3-10 for detailed instructions on using these routines. This section also describes the format of the optional initialization and termination routines you can include in a fragment, as well
as the structure of the code fragment resource.
Data Structures
This section describes the data structures that define the format of the data passed to a fragment’s initialization routine.
IMPORTANT
You need the information in this section only if your fragment (application, import library, or extension) contains an initialization routine. In addition, much of the information passed to an initialization routine is intended for use by language implementors. Most other developers are likely to need only the pointer to a file specification record passed to disk-based fragments. (This information allows the initialization routine to access its own resource fork.)s
Fragment Initialization Block
The Code Fragment Manager passes to your fragment’s initialization routine a pointer to a fragment initialization block, which contains information about the fragment. A fragment initialization block is defined by the InitBlock data type.
fragLocator A fragment location record that specifies the location of the fragment. See the following section for details about the structure
of a fragment location record.
libName A pointer to the name of the fragment being initialized. The name is a Pascal string (a length byte followed by the name itself).
reserved4a Reserved for use by Apple Computer.
reserved4b Reserved for use by Apple Computer.
reserved4c Reserved for use by Apple Computer.
reserved4d Reserved for use by Apple Computer.
IMPORTANT
The fields of a fragment initialization block are aligned in memory in accordance with 680x0 alignment conventions.s
Fragment Location Record
The fragLocator field of an initialization block contains a fragment location record that provides information about the location of a fragment. A fragment location record is defined by the FragmentLocator data type.
where A selector that determines which member of the following union is relevant. This field can contain one of these constants:
enum {
kInMem, /*container in memory*/
kOnDiskFlat, /*container in a data fork*/
kOnDiskSegmented /*container in a resource*/
};
inMem A memory location record.
onDisk A disk location record.
inSegs A segment location record.
IMPORTANT
IMPORTANT
The fields of a fragment location record are aligned in memory in accordance with 680x0 alignment conventions.s
Memory Location Record
For fragments located in memory, the inMem field of a fragment location record contains a memory location record, which specifies the location of the fragment in memory. A memory location record is defined by the MemFragment data type.
struct MemFragment {
Ptr address; /*pointer to start of fragment*/
long length; /*length of fragment*/
Boolean inPlace; /*is data section in place?*/
};
typedef struct MemFragment MemFragment;
Field descriptions
address A pointer to the beginning of the fragment in memory.
length The length, in bytes, of the fragment.
inPlace A Boolean value that specifies whether the container’s data section is instantiated in place (true) or elsewhere (false).
IMPORTANT
The fields of a memory location record are aligned in memory in accordance with 680x0 alignment conventions.s
Disk Location Record
For fragments located in the data fork of a file on disk, the onDisk field of a fragment location record contains a disk location record, which specifies the location of the fragment. A disk location record is defined by the DiskFragment data type.
struct DiskFragment {
FSSpecPtr fileSpec; /*pointer to FSSpec*/
long offset; /*offset to start of fragment*/
long length; /*length of fragment*/
};
typedef struct DiskFragment DiskFragment;
Field descriptions
fileSpec A pointer to a file specification record (a data structure of type FSSpec) for the data fork of a file. This pointer is valid only while the initialization routine is executing. If you need to access the information in the file specification record at any later time, you must make a copy of that record.
offset The offset, in bytes, from the beginning of the file’s data fork to the beginning of the fragment.
length The length, in bytes, of the fragment. If this field contains the value 0, the fragment extends to the end-of-file.
IMPORTANT
The fields of a disk location record are aligned in memory in accordance with 680x0 alignment conventions.s
Segment Location Record
For fragments located in the resource fork of a file on disk, the inSegs field of a fragment location record contains a segment location record, which specifies the location of the fragment. A segment location record is defined by the SegmentedFragment data type.
fileSpec A pointer to a file specification record (a data structure of type FSSpec) for the resource fork of a file. This pointer is valid only while the initialization routine is executing. If you need to access the information in the file specification record at any later time, you must make a copy of that record.
rsrcType The resource type of the resource containing the fragment.
rsrcID The resource ID of the resource containing the fragment.
IMPORTANT
The fields of a segment location record are aligned in memory in accordance with 680x0 alignment conventions.s
Code Fragment Manager Routines
You can use the routines provided by the Code Fragment Manager to
n load a fragment by filename or library name
n identify an import library that is already loaded
n unload a fragment
n find a symbol by name in a fragment
n find all the symbols in a fragment
Loading Fragments
The Code Fragment Manager provides three functions that you can use to load various kinds of fragments: GetDiskFragment, GetMemFragment, and GetSharedLibrary. Loading involves finding the specified fragment, reading it into memory (if it isn’t already in memory), and preparing it for execution. The Code Fragment Manager attempts to resolve all symbols imported by the fragment; to do so may involve loading import libraries.
If the fragment loading fails, the Code Fragment Manager returns an error code. Note, however, that the error encountered is not always in the fragment you asked to load. Rather, the error might have occurred while attempting to load an import library that the fragment you want to load depends on. For this reason, the Code Fragment Manager also returns, in the errName parameter, the name of the fragment that caused the load to fail. Although fragment names are restricted to 63 characters, the errName parameter is declared as type Str255; doing this allows future versions of the Code Fragment Manager to return a more informative message in the errName parameter.
GetDiskFragment
You can use the GetDiskFragment function to locate and possibly also load a fragment contained in a file’s data fork into your application’s context.
OSErr GetDiskFragment (FSSpecPtr fileSpec, long offset,
long length, Str63 fragName,
LoadFlags findFlags, ConnectionID *connID,
Ptr *mainAddr, Str255 errName);
fileSpec A file system specification that identifies the disk-based fragment to load.
offset The number of bytes from the beginning of the file’s data fork at which the beginning of the fragment is located.
length The length (in bytes) of the fragment. Specify the constant kWholeFork for this parameter if the fragment extends to the end-of-file of the data fork. Specify a nonzero value for the exact length of the fragment.
fragName An optional name of the fragment. (This information is used primarily to allow you to identify the fragment during debugging.)
findFlags A flag that specifies the operation to perform on the fragment. See the description below for the values you can pass in this parameter.
connID On exit, the connection ID that identifies the connection to the fragment. You can pass this ID to other Code Fragment Manager routines.
mainAddr On exit, the main address of the fragment. The value returned is specific to the fragment itself. Your application can use this parameter for its
own purposes.
errName On exit, the name of the fragment that could not successfully be loaded. This parameter is meaningful only if the call to GetDiskFragment fails.
DESCRIPTION
The GetDiskFragment function locates and possibly also loads a disk-based fragment into your application’s context. The actions of GetDiskFragment depend on the action flag you pass in the findFlags parameter. The Code Fragment Manager recognizes these constants:
enum {
kLoadLib = 1, /*load fragment*/
kFindLib = 2, /*find fragment*/
kLoadNewCopy = 5 /*load fragment with new copy of data*/
};
The kFindLib constant specifies that the Code Fragment Manager search for the specified fragment. If the fragment is already prepared and connected to your application, GetDiskFragment returns fragNoErr as its function result and the existing connection ID in the connID parameter. If the specified fragment is not found, GetDiskFragment returns the result code fragLibNotFound. If the specified fragment is found but could
not be connected to your application, GetDiskFragment returns the result code fragLibConnErr.
The kLoadLib constant specifies that the Code Fragment Manager search for the specified fragment and, if it finds it, load it into memory. If the fragment has already been loaded, it’s not loaded again. The Code Fragment Manager uses the data-
instantiation method specified in the fragment’s container (which is either global or per-connection instantiation).
The kLoadNewCopy constant specifies that the Code Fragment Manager load the specified fragment, creating a new copy of any writable data maintained by the fragment. You specify kLoadNewCopy to obtain one instance per load of the fragment’s data and to override the data-instantiation method specified in the container itself. This is most useful for application extensions (for example, drop-in tools).
RESULT CODESfragNoErr 0 No error
paramErr –50 Parameter error
fragLibNotFound –2804 Specified fragment not found
fragHadUnresolveds –2807 Loaded fragment has unacceptable unresolved symbols
fragNoMem –2809 Not enough memory for internal bookkeeping
fragNoAddrSpace –2810 Not enough memory in user’s address
space for section
fragObjectInitSeqErr –2812 Order error during user initialization function
fragImportTooOld –2813 Import library is too old
fragImportTooNew –2814 Import library is too new
fragInitLoop –2815 Circularity in required initialization order
fragLibConnErr –2817 Error connecting to fragment
fragUserInitProcErr –2821 Initialization procedure did not return noErr
SEE ALSO
See “Loading Code Fragments” on page 3-10 for more details on the fragment-
loading process.
GetMemFragment
You can use the GetMemFragment function to prepare a memory-based fragment.
OSErr GetMemFragment (Ptr memAddr, long length, Str63 fragName,
LoadFlags findFlags, ConnectionID *connID,
Ptr *mainAddr, Str255 errName);
memAddr The address of the fragment.
length The size, in bytes, of the fragment.
fragName The name of the fragment. (This information is used primarily to allow you to identify the fragment during debugging.)
findFlags A flag that specifies the operation to perform on the fragment. See the description of the GetDiskFragment function on page 3-19 for the values you can pass in this parameter.
connID On exit, the connection ID that identifies the connection to the fragment. You can pass this ID to other Code Fragment Manager routines (for example, CloseConnection).
mainAddr On exit, the main address of the fragment. The value returned is specific to the fragment itself.
errName On exit, the name of the fragment that could not successfully be loaded. This parameter is meaningful only if the call to GetMemFragment fails.
DESCRIPTION
The GetMemFragment function prepares for subsequent execution a fragment that
is already loaded into memory. This function is most useful for handling code that
is contained in a resource. You can read the resource data into memory using
normal Resource Manager routines (for example, Get1Resource) and then call GetMemFragment to complete the processing required to prepare it for use (for example, to resolve any imports and execute the fragment’s initialization routine).
sWARNING
You must lock the resource-based fragment into memory (for example, by calling HLock) before calling GetMemFragment. You must not unlock the memory until you’ve closed the connection to the fragment (by calling CloseConnection).s
RESULT CODESfragNoErr 0 No error
paramErr –50 Parameter error
fragLibNotFound –2804 Specified fragment not found
fragHadUnresolveds –2807 Loaded fragment has unacceptable unresolved symbols
fragNoMem –2809 Not enough memory for internal bookkeeping
fragNoAddrSpace –2810 Not enough memory in user’s address space for section
fragObjectInitSeqErr –2812 Order error during user initialization function
fragImportTooOld –2813 Import library is too old
fragImportTooNew –2814 Import library is too new
fragInitLoop –2815 Circularity in required initialization order
fragLibConnErr –2817 Error connecting to fragment
fragUserInitProcErr –2821 Initialization procedure did not return noErr
SEE ALSO
See “Loading Code Fragments” on page 3-10 for more details on the fragment-
loading process.
GetSharedLibrary
You can use the GetSharedLibrary function to locate and possibly also load an import library into your application’s context.
archType The instruction set architecture of the import library. For the PowerPC architecture, use the constant kPowerPCArch. For the 680x0 architecture, use the constant kMotorola68KArch.
findFlags A flag that specifies the operation to perform on the import library. See the description of the GetDiskFragment function on page 3-19 for the values you can pass in this parameter.
connID On exit, the connection ID that identifies the connection to the import library. You can pass this ID to other Code Fragment Manager routines.
mainAddr On exit, the main address of the import library. The value returned is specific to the import library itself and is not used by the Code
Fragment Manager.
errName On exit, the name of the fragment that could not successfully be loaded. This parameter is meaningful only if the call to GetSharedLibrary fails.
DESCRIPTION
The GetSharedLibrary function locates the import library named by the libName parameter and possibly also loads that import library into your application’s context. The actions of GetSharedLibrary depend on the action flag you pass in the findFlags parameter; pass kFindLib to get the connection ID of an existing connection to the specified fragment, kLoadLib to load the specified fragment, or kLoadNewCopy to load the fragment with a new copy of the fragment’s data section.
The GetSharedLibrary function does not resolve any unresolved imports in your application. In particular, you cannot use it to resolve any weak imports in your
code fragment.
RESULT CODESfragNoErr 0 No error
paramErr –50 Parameter error
fragLibNotFound –2804 Specified fragment not found
fragHadUnresolveds –2807 Loaded fragment has unacceptable unresolved symbols
fragNoMem –2809 Not enough memory for internal bookkeeping
fragNoAddrSpace –2810 Not enough memory in user’s address space for section
fragObjectInitSeqErr –2812 Order error during user initialization function
fragImportTooOld –2813 Import library is too old
fragImportTooNew –2814 Import library is too new
fragInitLoop –2815 Circularity in required initialization order
fragLibConnErr –2817 Error connecting to fragment
fragUserInitProcErr –2821 Initialization procedure did not return noErr
SEE ALSO
See “Loading Code Fragments” on page 3-10 for more details on the fragment-
loading process.
Unloading Fragments
The Code Fragment Manager provides one function that you can use to close an existing connection to a fragment.
CloseConnection
You can use the CloseConnection function to close a connection to a fragment.
OSErr CloseConnection (ConnectionID *connID);
connID A connection ID.
DESCRIPTION
The CloseConnection function closes the connection to a fragment indicated by the connID parameter. CloseConnection decrements the count of existing connections to the specified fragment and, if the resulting count is 0, calls the fragment’s termination routine and releases the memory occupied by the code and data sections of the fragment. If the resulting count is not 0, any per-connection data is released but the code section remains in memory.
When a fragment is unloaded as a result of its final connection having been closed, all libraries that depend on that fragment are also released, provided that their usage counts are also 0.
The Code Fragment Manager automatically closes any connections that remain
open at the time ExitToShell is called for your application, so you need to call CloseConnection only for fragments you wish to unload before your application terminates.
SPECIAL CONSIDERATIONS
You can close a connection only to the root of a loading sequence (that is, the fragment whose loading triggered the entire load chain).
RESULT CODESfragNoErr 0 No error
fragConnectionIDNotFound –2801 Connection ID is not valid
Finding Symbols
The Code Fragment Manager provides three functions that you can use to find the symbols exported by a fragment and get information about them: FindSymbol, CountSymbols, and GetIndSymbol.
FindSymbol
You can use the FindSymbol function to search for a specific exported symbol.
symAddr On exit, the address of the symbol whose name is symName.
symClass On exit, the class of the symbol whose name is symName. See the description below for a list of the recognized symbol classes.
DESCRIPTION
The FindSymbol function searches the code fragment identified by the connID parameter for the symbol whose name is specified by the symName parameter. If that symbol is found, FindSymbol returns the address of the symbol in the symAddr parameter and the class of the symbol in the symClass parameter. The currently recognized symbol classes are defined by constants.
enum {
kCodeSymbol = 0, /*a code symbol*/
kDataSymbol = 1, /*a data symbol*/
kTVectSymbol = 2 /*a transition vector symbol*/
};
Because a fragment’s code is normally exported through transition vectors to that code, the value kCodeSymbol is not returned in the PowerPC environment. You can use the other two constants to distinguish exports that represent code (of class kTVectSymbol) from those that represent general data (of class kDataSymbol).
RESULT CODESfragNoErr 0 No error
fragConnectionIDNotFound –2801 Connection ID is not valid
fragSymbolNotFound –2802 Symbol was not found in connection
CountSymbols
You can use the CountSymbols function to determine how many symbols are exported from a specified fragment.
OSErr CountSymbols (ConnectionID connID, long *symCount);
connID A connection ID.
symCount On exit, the number of exported symbols in the fragment whose connection ID is connID.
DESCRIPTION
The CountSymbols function returns, in the symCount parameter, the number of symbols exported by the fragment whose connection ID is connID. You can use the value returned in symCount to index through all the exported symbols in a particular fragment (using the GetIndSymbol function).
RESULT CODESfragNoErr 0 No error
fragConnectionIDNotFound –2801 Connection ID is not valid
GetIndSymbol
You can use the GetIndSymbol function to get information about the exported symbols in a fragment.
OSErr GetIndSymbol (ConnectionID connID, long symIndex,
Str255 symName, Ptr *symAddr,
SymClass *symClass);
connID A connection ID.
symIndex A symbol index. The value of this parameter should be greater than
or equal to 1 and less than or equal to the value returned by the CountSymbols function.
symName On exit, the name of the indicated symbol.
symAddr On exit, the address of the indicated symbol.
symClass On exit, the class of the indicated symbol.
DESCRIPTION
The GetIndSymbol function returns information about a particular symbol exported by the fragment whose connection ID is connID. If GetIndSymbol executes successfully, it returns the symbol’s name, starting address, and class in the symName, symAddr, and symClass parameters, respectively. See the description of the FindSymbol function (page 3-24) for a list of the values that can be returned in the symClass parameter.
A fragment’s exported symbols are retrieved in no predetermined order.
RESULT CODESfragNoErr 0 No error
fragConnectionIDNotFound –2801 Connection ID is not valid
fragSymbolNotFound –2802 Symbol was not found in connection
Fragment-Defined Routines
This section describes the initialization and termination routines that you can define for a fragment.
ConnectionInitializationRoutine
You can define a fragment initialization routine that is executed by the Code Fragment Manager when the fragment is first loaded into memory and prepared for execution. An initialization routine has the following type definition:
typedef OSErr ConnectionInitializationRoutine
(InitBlockPtr initBlkPtr);
initBlkPtr
A pointer to a fragment initialization block specifying information about the fragment.
Parameter blockÆ contextID long A context ID.
Æ closureID long A closure ID.
Æ connectionID long A connection ID.
Æ fragLocator FragmentLocator A fragment location block.
Æ libName Ptr A pointer to fragment’s name.
Æ reserved4a long Reserved.
Æ reserved4b long Reserved.
Æ reserved4c long Reserved.
Æ reserved4d long Reserved.
DESCRIPTION
A fragment’s initialization routine is executed immediately after the fragment has been loaded into memory (if necessary) and prepared for execution, and immediately before the fragment’s main routine (if it has one) is executed. The initialization routine is passed a pointer to an initialization block, which contains information about the fragment, such as its location and connection ID. See “Fragment Initialization Block” on page 3-15 for a description of the fields of the initialization block.
You can use the initialization routine to perform any tasks that need to be performed before any of the code or data in the fragment is accessed. For example, you might want to open the fragment’s resource fork (if it has one). You can determine the location of the fragment’s container from the FragmentLocator field of the fragment initialization block whose address is passed to your initialization routine.
RESULT CODES
Your initialization routine should return noErr if it executes successfully, and some other result code if it does not. If your initialization routine returns any result code other than noErr, the entire load fails and the error fragUserInitProcErr is returned to the code that requested the root load.
ConnectionTerminationRoutine
You can define a fragment termination routine that is executed by the Code Fragment Manager when a fragment is unloaded from memory. A termination routine has the following type definition:
typedef void ConnectionTerminationRoutine (void);
DESCRIPTION
A fragment’s termination routine is executed immediately before the fragment is unloaded from memory. You can use the termination routine to perform any necessary clean-up tasks, such as closing open resource files or disposing of any memory allocated by the fragment.
Note that a termination routine is not passed any parameters and does not return any result. You are expected to maintain any information about the fragment (such as file reference numbers of any open files) in its static data area.
Resources
This section describes the code fragment resource, a resource of type 'cfrg' that is used by the Code Fragment Manager when loading fragments such as applications and import libraries.
This section describes the structure of this resource after it is compiled by the Rez resource compiler, available from APDA. If you are interested in creating the Rez input file for this resource, see “Creating a Code Fragment Resource” on page 3-12 for detailed information.
The Code Fragment Resource
You use a code fragment resource to specify some characteristics of a code fragment. For an application, the code fragment resource indicates to the Process Manager that the application’s data fork contains an executable code fragment. For an import library, the code fragment resource specifies the library’s name and version information.
IMPORTANT
A code fragment resource must have resource ID 0.s
Figure 3-1 shows the structure of a compiled code fragment resource.
Figure 3-1 Structure of a compiled code fragment ('cfrg') resource
The compiled version of a code fragment resource contains the following elements:
n Reserved. The first two long integers are reserved and should be set to 0.
n Version information. This field specifies the current version of the 'cfrg' resource. The current version is 0x00000001.
n Reserved. The next four long integers are reserved and should be set to 0.
n Number of fragment descriptions. This field specifies the number of code fragment information records that follow this field in the resource. (The value in this field should be the actual number of information records that follow, beginning with 1.)
Following the array count is an array of code fragment information records. A single file can include one or more containers. Similarly, it might occasionally be useful to assign more than one name to a single import library or application. Typically, however, both applications and import libraries include just a single code fragment information record in their 'cfrg' resources. Each record has the format illustrated in Figure 3-2.
Figure 3-2 The format of a code fragment information record
A code fragment information record contains the following elements:
n The instruction set architecture. You can use the Rez constant kPowerPC ('pwpc') to specify the PowerPC instruction set architecture.
n The update level. For an import library, you can specify either the value kFullLib (0), to indicate that the library is a base library (not an update of some other library), or the value kUpdateLib (1), to indicate that the library updates only part of some other library. Applications should specify the value kFullLib in this field.
n The current version number. For an import library, this field specifies the implementa-
tion version. This field has the same format as the first 4 bytes of a resource of type 'vers'. See the chapter “Finder Interface” in Inside Macintosh: Macintosh Toolbox Essentials for details on the structure of a 'vers' resource.
n The oldest definition version number. For an import library, this field specifies the oldest version of the definition library with which the implementation import library is compatible. This field has the same format as the first 4 bytes of a resource of
type 'vers'.
n The application stack size. For an application, this field specifies the minimum size, in bytes, of the application stack. You can use the Rez constant kDefaultStackSize (0) to indicate that the stack should be given the default size for the current software and hardware configuration. If you determine at run time that your application needs a larger or smaller stack, you can use the standard stack-adjusting techniques that call GetApplLimit and SetApplLimit.
n The application’s library directory. For an application, this field specifies the resource ID of an alias resource (a resource of type 'alis') in the application’s resource fork that describes the application’s load directory. See “Import Library Searching” on page 3-5 for more information about load directories. For information about alias resources, see the chapter “Alias Manager” in Inside Macintosh: Files.
n A usage field. This field specifies the type of fragment that this record describes. The value kIsLib (0) indicates that the fragment is an import library. The value kIsApp (1) indicates that the fragment is an application. The value kIsDropIn (2) indicates that the fragment is an extension. The Code Fragment Manager recognizes only the values kIsLib and kIsApp. The value kIsDropIn is provided to allow you to put private application extensions in a file and not have the Code Fragment Manager recognize them as shared libraries.
n A location field. This field specifies the location of the fragment’s container. The value kInMem (0) indicates that the container is in memory (usually in ROM). This value is intended for use by the Operating System; in general, you should not use it. The value kOnDiskFlat (1) indicates that the container is in the data fork of some file. The value kOnDiskSegmented (2) indicates that the container is in a resource in the resource fork of some file.
n The offset to the beginning of the fragment. The interpretation of this field depends
on the value specified in the location field immediately preceding this field. If the location field has the value kInMem, this field is the address in memory of the begin-
ning of the fragment. If the location field has the value kOnDiskFlat, this field is the number of bytes from the beginning of the data fork to the beginning of the fragment itself. You can use the Rez constant kZeroOffset (0) to specify an offset of 0 bytes. If the location field has the value kOnDiskSegmented, this field is the resource type (of type OSType) of the resource that contains the fragment.
n The length of the fragment. The interpretation of this field depends on the value specified in the location field immediately preceding the offset field. If the location field has the value kInMem, this field is the address in memory of the end of the fragment. If the location field has the value kOnDiskFlat, this field is the length, in bytes, of the fragment. You can use the Rez constant kWholeFork (0) to indicate that the fragment occupies the entire fork. If the location field has the value kOnDiskSegmented, this field is the sign-extended resource ID of the resource that contains the fragment.
n Reserved. The next two long integers are reserved and should be set to 0.
n The total length of the code fragment information record. This field specifies
the length, in bytes, of this code fragment information record, including the
fragment name and any pad bytes added to the name field.
n The fragment’s name. This field is a Pascal string that indicates the name of the application or import library. This is the default name used by the debugger for this fragment. This field is padded with null bytes, if necessary, so that the information record extends to a 4-byte boundary.
Summary of the Code Fragment Manager
C Summary
Constants
/*Gestalt selector and response bits*/
#define gestaltCFMAttr 'cfrg' /*Code Fragment Manager attributes*/
enum {
gestaltCFMPresent = 0 /*set if Code Fragment Mgr is present*/
};
#define kPowerPCArch 'pwpc' /*PowerPC instruction set architecture*/
#define kMotorola68KArch 'm68k' /*680x0 instruction set architecture*/
#define kNoLibName ((unsigned char *) 0)
#define kNoConnectionID ((ConnectionID) 0)
#define kUnresolvedSymbolAddress ((Ptr) 0x0)
enum {
kLoadLib = 1, /*load fragment*/
kFindLib = 2, /*find fragment*/
kLoadNewCopy = 5 /*load fragment with new copy of data*/
};
enum {
kCodeSymbol = 0, /*a code symbol*/
kDataSymbol = 1, /*a data symbol*/
kTVectSymbol = 2 /*a transition vector symbol*/
};
enum {
/*selectors for fragment location record*/
kInMem, /*container in memory*/
kOnDiskFlat, /*container in a data fork*/
kOnDiskSegmented /*container in a resource*/
};
Data Types
typedef long ConnectionID; /*connection ID number*/
typedef unsigned long LoadFlags; /*a flag long word*/
fragCorruptErr –2820 Fragment container is corrupted
fragUserInitProcErr –2821 Initialization procedure did not return noErr
fragAppNotFound –2822 No application found in 'cfrg' resource
fragArchErr –2823 Fragment targeted for unacceptable architecture
fragInvalidFragmentUsage –2824 Fragment is used invalidly
Listing 4-0
Table 4-0
Exception Manager
Contents
About the Exception Manager4-3
Exception Contexts4-4
Types of Exceptions4-5
Using the Exception Manager4-6
Installing an Exception Handler4-6
Writing an Exception Handler4-7
Exception Manager Reference4-9
Constants4-9
Exception Kinds4-9
Memory Reference Kinds4-11
Data Structures4-12
Machine Information Records4-12
Register Information Records4-12
Floating-Point Information Records4-14
Memory Exception Records4-15
Exception Information Records4-16
Exception Manager Routines4-17
Application-Defined Routines4-17
Summary of the Exception Manager4-19
C Summary4-19
Constants4-19
Data Types4-19
Exception Manager Routines4-22
Application-Defined Routines4-22
Exception Manager
This chapter describes the Exception Manager, the part of the Macintosh system software that handles exceptions that occur during the execution of PowerPC applications or other software. The Exception Manager provides a simple way for your application to handle exceptions that occur in its context.
You need the information in this chapter if you need to handle exceptions that occur in native PowerPC code. If your application or other software is written in 680x0 code and therefore executes under the 68LC040 Emulator on PowerPC processor-based Macintosh computers, you do not in general need to read this chapter, because the existing 680x0 mechanism for handling exceptions is fully supported by the emulator.
IMPORTANT
The Exception Manager is available only in the system software for PowerPC processor-based Macintosh computers. In addition, not all features described here are available in the first version. For example, the Exception Manager in the first version does not return exceptions that arise during floating-point calculations. If your application performs floating-point operations and needs to handle any exceptions that arise during those operations, you should use the exception-
handling mechanisms provided by the PowerPC Numerics library. See Inside Macintosh: PowerPC Numerics for complete information.s
To use this chapter, you should already be generally familiar with the Macintosh Operating System. See the books Inside Macintosh: Processes and Inside Macintosh: Memory for information about the run-time architecture of the 680x0 environment. You also need to be familiar with the run-time architecture of PowerPC processor-based Macintosh computers, as explained in the chapter “Introduction to PowerPC System Software.”
This chapter begins with a description of exceptions and their handling in the PowerPC native environment. Then it shows how to use the Exception Manager to install your own exception handler.
About the Exception Manager
An exception is an error or other special condition detected by the microprocessor in the course of program execution. When an exception occurs, the Operating System transfers control synchronously to the relevant exception handler, which attempts to recover gracefully from the error or special condition. The kinds of errors or other conditions that give rise to exceptions differ from one processor to another. On 680x0 processors, for example, an exception is generated if the currently executing program attempts to divide by zero. By contrast, the PowerPC processor does not generate an exception under
that condition.
In general, applications or other types of software (including much of the Macintosh Operating System and the Macintosh Toolbox) cannot tolerate the occurrence of exceptions. To provide some measure of protection from potentially fatal exceptions, the Operating System installs its own set of exception handlers. You can, if necessary, use the Exception Manager to install application-specific exception handlers. Any exception handlers that you install apply only to your current context and only to exceptions that are not first intercepted and handled by the Operating System.
IMPORTANT
Not all exceptions that occur in your application’s context are passed to your exception handler. Certain exceptions (for example, page faults) are handled completely by the Operating System’s exception handlers. As a result, those exceptions do not affect the normal execution of your application or other software.s
When your exception handler is called, the Exception Manager passes it a parameter that contains information about the state of the machine at the time the exception occurred. On PowerPC processor-based Macintosh computers, this information includes
n the kind of exception that occurred
n the contents of the 32 general-purpose registers
n the contents of the special-purpose registers (such as the Link Register and the Condition Register)
n the contents of the 32 floating-point registers
Your exception handler can handle the exception in various ways. For example, it might modify the machine state and then resume execution. Similarly, your exception handler might simply transfer control to some other code. In rare instances, however, your exception handler might not be able to handle the exception; when this happens, the exception is usually fatal to your application.
Exception Contexts
In the first version of the system software for PowerPC processor-based Macintosh computers, each application can install its own exception handler, which remains the active handler as long as that application is the current application. In other words, the exception handler of the current application is called for all exceptions not intercepted
by the Operating System. In general, this mechanism results in the execution of the appropriate exception handler. It’s possible, however, for code you install to cause exceptions that are handled by some other application’s exception handler. For instance, exceptions that arise during the asynchronous execution of code (such as VBL tasks, Time Manager tasks, and I/O completion routines) are handled by the exception handler of whatever application happens to be the current application at the time the exception occurs. If that application has not installed an exception handler, the exception might not be handled.
All asynchronous code executed in the first version of the system software for PowerPC processor-based Macintosh computers is executed under the 68LC040 Emulator, in which case the exceptions are handled using the existing 680x0 mechanisms. If, however, a routine executed asynchronously calls some code that is native PowerPC code, and if that native code causes an exception to occur, then the current application’s exception handler (if any) is called to handle the exception.
Types of Exceptions
In the first version of the system software for PowerPC processor-based Macintosh computers, the following conditions can cause exceptions while your application or other software is executing in native mode:
n an attempt to write to write-protected memory
n an attempt to access (that is, read, write, or fetch) data at a logical address that is
not assigned
n an attempt to execute trap instructions or other instructions that are not part of the supported application programming interface
n an attempt to execute invalid instructions or an invalid form of a valid instruction
n an attempt to execute privileged instructions when the system is not in
privileged mode
n in appropriate circumstances, reaching a breakpoint
n in appropriate circumstances, reaching a trace point
The Exception Manager defines a number of exception codes that indicate these and other conditions. An exception code is a constant that indicates which kind of exception has occurred.
typedef unsigned long ExceptionKind; /*kind of exception*/
terminationException = 15 /*task is being terminated*/
};
Not all of these exception codes are used in the first version of the system software for PowerPC processor-based Macintosh computers; see “Exception Kinds” on page 4-9 for a complete explanation of these constants.
Using the Exception Manager
The Exception Manager provides a routine that you can use to install an exception handler and remove an exception handler. This section describes how to use this routine and how to write an exception handler.
Installing an Exception Handler
You can install an exception handler for your application’s context by calling the InstallExceptionHandler routine. You pass InstallExceptionHandler the address of your exception handler:
The InstallExceptionHandler function replaces any existing exception handler already installed for the current execution context (that is, for the current application) and returns the address of that previously installed handler. Listing 4-1 shows a
routine that installs an exception handler as part of a wrapper around the NewEmptyHandle function.
Listing 4-1 Installing an exception handler
static jump_buf *curJmpBuf;
Handle __NewEmptyHandle (ushort trapWord)
{
Handle returnVal;
OSErr myErr;
jmp_buf localJump, *oldJump;
ExceptionHandler prevHandler;
oldJump = curJmpBuf; /*save current jump address*/
curJmpBuf = &localJump; /*install new jump address*/
curJmpBuf = oldJump; /*restore original jump address*/
return (returnVal);
}
You can remove the current exception handler from your application’s context by passing the value nil as the parameter to InstallExceptionHandler, as follows:
When your handler is called, the Exception Manager passes it the address of an exception information record, which contains information about the exception, such as its type and the state of the machine at the time the exception occurred. The exception information record is defined by the ExceptionInformation data type.
The theKind field contains an exception code. The fields machineState and registerImage contain information about the special-purpose and general-purpose registers, respectively. The values in the special-purpose registers are contained in a machine information record, defined by the MachineInformation data type.
struct MachineInformation {
UnsignedWide CTR; /*Count Register*/
UnsignedWide LR; /*Link Register*/
UnsignedWide PC; /*Program Counter Register*/
unsigned long CR; /*Condition Register*/
unsigned long XER; /*Fixed-Point Exception Register*/
As you can see, this record contains primarily the values in the special-purpose registers. The values in the general-purpose registers are encoded using a structure of type RegisterInformation, which is effectively an array of 32 register values.
Note
For a more detailed description of the exception information record
and its associated data types, see “Data Structures” beginning on page 4-12.u
Your exception handler can perform any actions necessary or useful for handling the exception. You might attempt to recover from the error or simply terminate your application gracefully. The specific actions you perform depend, of course, on the type
of exception that has occurred. In general, however, you will probably want to use
one or the other of two basic techniques for recovering from the exception.
n Your exception handler might simply transfer control away from the point of execution. For example, you might jump back into your main event loop or into
some error recovery code.
n Alternatively, your exception handler might attempt to repair the cause of the excep-
tion by suitably modifying the state of the machine (as reported to your exception handler in an exception information record). You can alter any piece of that machine state, including the PC register. After you have suitably modified the relevant data, your handler should return, passing back a result code. The Exception Manager inspects the result code you return and determines what further actions to take. If you pass back noErr, then the Exception Manager restores the machine state to the state contained in the exception information record and resumes execution. If you pass back any other result code, the Operating System proceeds as if the exception had occurred but no exception handler was present.
Listing 4-2 shows a simple exception handler MyHandler.
As you can see, the MyHandler exception handler looks for memory-related exceptions and, if it finds any, transfers control by calling the longjmp function.
sWARNING
sWARNING
Returning a value other than noErr from your exception handler is likely to cause the current application to be terminated.s
sWARNING
Your exception handler must be reentrant if it might itself cause any exceptions to be generated. For example, if your exception handler
calls the Debugger or DebugStr routine, the trap exception (of type trapException) is generated. Normally, a debugger intercepts and handles those kinds of exceptions. If, however, no debugger is installed in the system, your exception handler might be called repeatedly. Eventually, the stack will grow to the lowest memory address, overwriting essential data and causing a system crash.s
Exception Manager Reference
This section describes the constants, data structures, and routine provided by the Exception Manager. See “Using the Exception Manager” beginning on page 4-6
for detailed instructions on using that routine.
Constants
This section describes the constants provided by the Exception Manager.
Exception Kinds
The Exception Manager indicates to your exception handler the kind of exception
that has occurred by passing it an exception code. The exception kind is indicated by
a constant.
Note
Some kinds of exceptions occur only on specific types of
processors or only in specific system software versions.u
terminationException = 15 /*task is being terminated*/
};
Constant descriptions
unknownException
Unknown kind of exception. This exception code is defined for completeness only; it is never actually passed to an exception handler.
illegalInstructionException
Illegal instruction exception. The processor attempted to decode an instruction that is either illegal or unimplemented.
trapException Unknown trap type exception. The processor decoded a trap type instruction that is not used by the system software.
accessException
Memory access exception. A memory reference resulted in a page fault because the physical address is not accessible.
unmappedMemoryException
Unmapped memory exception. A memory reference was made to an address that is unmapped.
excludedMemoryException
Excluded memory exception. A memory reference was made to an excluded address.
readOnlyMemoryException
Read-only memory exception. A memory reference was made to an address that cannot be written to.
unresolvablePageFaultException
Unresolvable page fault exception. A memory reference resulted in a page fault that could not be resolved. The theError field of the memory exception record contains a status value indicating the reason for this unresolved page fault.
privilegeViolationException
Privilege violation exception. The processor decoded a privileged instruction but was not executing in the privileged mode.
traceException
Trace exception. This exception is used by debuggers to support single-step operations.
instructionBreakpointException
Instruction breakpoint exception. This exception is used by debuggers to support breakpoint operations.
dataBreakpointException
Data breakpoint exception. This exception is used by debuggers to support breakpoint operations.
integerException
Integer exception. This exception is not used by PowerPC processors.
floatingPointException
Floating-point arithmetic exception. The floating-point processor has exceptions enabled and an exception has occurred. (This exception is not used in the first version of the system software
for PowerPC processor-based Macintosh computers.)
stackOverflowException
Stack overflow exception. The stack limits have been exceeded and the stack cannot be expanded. (This exception is not used in the first version of the system software for PowerPC processor-based Macintosh computers.)
terminationException
Termination exception. The task is being terminated. (This exception is not used in the first version of the system software for PowerPC processor-based Macintosh computers.)
Memory Reference Kinds
For each memory-related exception, the Exception Manager returns a memory exception record. The theReference field of that record contains a memory reference code that indicates the kind of memory operation that caused the exception.
enum {
/*memory reference codes*/
writeReference = 0, /*write operation*/
readReference = 1, /*read operation*/
fetchReference = 2 /*fetch operation*/
};
Constant descriptions
writeReference
The operation was an attempt to write data to memory.
readReference The operation was an attempt to read data from memory.
fetchReference The operation was an attempt to fetch a processor instruction. (Not all processors are able to distinguish read operations from fetch operations. As a result, fetch operation failures might instead be reported as failed read operations.)
Data Structures
This section describes the data structures provided by the Exception Manager.
Machine Information Records
The Exception Manager uses a machine information record to encode the state of the special-purpose registers at the time an exception occurs. A machine information record is defined by the MachineInformation data type.
struct MachineInformation {
UnsignedWide CTR; /*Count Register*/
UnsignedWide LR; /*Link Register*/
UnsignedWide PC; /*Program Counter Register*/
unsigned long CR; /*Condition Register*/
unsigned long XER; /*Fixed-Point Exception Register*/
The fields CTR, LR, and PC are declared as the 64-bit type UnsignedWide to allow compatibility with 64-bit processors.
On 32-bit processors, the register values are returned in the
low-order 32 bits. The high-order 32 bits are undefined.u
Field descriptions
CTR The contents of the Count Register (CTR).
LR The contents of the Link Register (LR).
PC The contents of the Program Counter Register (PC).
CR The contents of the Condition Register (CR).
XER The contents of the Fixed-Point Exception Register (XER).
MSR The contents of the Machine State Register (MSR).
IMPORTANT
The fields of a machine information record are aligned in memory in accordance with 680x0 alignment conventions.s
Register Information Records
The Exception Manager uses a register information record to encode the state of the general-purpose registers at the time an exception occurs. A register information record is defined by the RegisterInformation data type.
R10 The contents of general-purpose register GPR10.
R11 The contents of general-purpose register GPR11.
R12 The contents of general-purpose register GPR12.
R13 The contents of general-purpose register GPR13.
R14 The contents of general-purpose register GPR14.
R15 The contents of general-purpose register GPR15.
R16 The contents of general-purpose register GPR16.
R17 The contents of general-purpose register GPR17.
R18 The contents of general-purpose register GPR18.
R19 The contents of general-purpose register GPR19.
R20 The contents of general-purpose register GPR20.
R21 The contents of general-purpose register GPR21.
R22 The contents of general-purpose register GPR22.
R23 The contents of general-purpose register GPR23.
R24 The contents of general-purpose register GPR24.
R25 The contents of general-purpose register GPR25.
R26 The contents of general-purpose register GPR26.
R27 The contents of general-purpose register GPR27.
R28 The contents of general-purpose register GPR28.
R29 The contents of general-purpose register GPR29.
R30 The contents of general-purpose register GPR30.
R31 The contents of general-purpose register GPR31.
IMPORTANT
The fields of a register information record are aligned in memory
in accordance with 680x0 alignment conventions.s
Floating-Point Information Records
The Exception Manager uses a floating-point information record to encode the state of the floating-point unit at the time an exception occurs. A floating-point information record is defined by the FPUInformation data type.
struct FPUInformation {
UnsignedWide Registers[32]; /*FPU registers*/
unsigned long FPSCR; /*status/control reg*/
};
typedef struct FPUInformation FPUInformation;
Field descriptions
Field descriptions
Registers The contents of the 32 floating-point registers. This array is zero-based; for example, the contents of FPR0 are accessed
as Registers[0].
FPSCR The contents of the Floating-Point Status and Control
Register (FPSCR).
IMPORTANT
The fields of a floating-point information record are aligned in memory in accordance with 680x0 alignment conventions.s
Memory Exception Records
The Exception Manager uses a memory exception record to present additional informa-
tion about an exception that occurs as the result of a failed memory reference. A memory exception record is defined by the MemoryExceptionInformation data type.
theArea The area containing the logical address of the exception. When the memory reference that caused the exception is to an unmapped range of the logical address space, this field contains the value kNoAreaID.
theAddress The logical address of the exception.
theError A status value. When the exception kind is unresolvablePageFaultException, this field contains a value that indicates the reason the page fault could not be resolved.
theReference The type of memory reference that caused the exception. This field contains one of these constants:
enum {
writeReference = 0, /*write operation*/
readReference = 1, /*read operation*/
fetchReference = 2 /*fetch operation*/
};
See “Memory Reference Kinds” on page 4-11 for a description of these constants.
IMPORTANT
IMPORTANT
The fields of a memory exception record are aligned in memory in accordance with 680x0 alignment conventions.s
Exception Information Records
The Exception Manager passes an exception information record to your exception handler whenever your handler is called as the result of some exception. The exception information record indicates the nature of the exception and provides other information that might be useful to your handler. An exception information record is defined by the ExceptionInformation data type.
theKind An exception code indicating the kind of exception that occurred. See “Exception Kinds” on page 4-9 for a list of the available exception codes.
machineState The state of the machine at the time the exception occurred. See “Machine Information Records” on page 4-12 for details on the MachineInformation data type.
registerImage The contents of the general-purpose registers at the time the exception occurred. See “Register Information Records” on page 4-12 for details on the RegisterInformation data type.
FPUImage The state of the floating-point processor at the time the exception occurred. See “Floating-Point Information Records” on page 4-14 for details on the FPUInformation data type.
memoryInfo The logical address of the location in memory that triggered
the exception.
IMPORTANT
The fields of an exception information record are aligned in memory in accordance with 680x0 alignment conventions.s
Exception Manager Routines
You can use the Exception Manager’s InstallExceptionHandler routine to install an exception handler or to remove an existing exception handler.
InstallExceptionHandler
You can use the InstallExceptionHandler function to install an exception handler.
extern ExceptionHandler InstallExceptionHandler
(ExceptionHandler theHandler);
theHandler
The address of the exception handler to be installed.
DESCRIPTION
The InstallExceptionHandler function installs the exception handler specified by the theHandler parameter. That handler replaces any existing exception handler associated with the current execution context. The newly installed handler remains active until you install some other handler or until you remove the current handler by calling InstallExceptionHandler with theHandler set to nil.
IMPORTANT
The theHandler parameter must be the address of a transition vector for the exception handler, not a universal procedure pointer.s
The InstallExceptionHandler function returns the address of any existing exception handler as its function result. If there is no exception handler in place
for the current execution context, InstallExceptionHandler returns nil.
SPECIAL CONSIDERATIONS
The InstallExceptionHandler function is available to any code executing in the PowerPC native environment. You do not need to call it if your application or other software exists as 680x0 code and hence executes under the 68LC040 Emulator on PowerPC processor-based Macintosh computers.
Application-Defined Routines
This section describes exception handlers, routines that you install using the InstallExceptionHandler routine to handle specific types of exceptions.
The address of an exception information block describing the exception that triggered the exception handler.
DESCRIPTION
You pass the address of your MyExceptionHandler routine to the Exception Manager’s InstallExceptionHandler function. The Exception Manager subsequently calls your exception handler for all exceptions that arise in your application’s context that are not intercepted by the Operating System.
Your exception handler can take whatever steps are necessary to handle the exception or to correct the error or special condition that caused the exception. If your handler is successful, it should return the noErr result code. If you pass back noErr, the Exception Manager restores the machine state to the state contained in the exception information record pointed to by the theException parameter and resumes execution.
If your handler is not able to handle the exception, it should return some other result code. However, if your handler returns a nonzero result code, the current application is likely to be terminated by the Process Manager.
An exception handler uses the same stack that is active at the time an exception occurs. To ensure that no stack data is destroyed, the Exception Manager advances the stack pointer prior to calling the exception handler.
SPECIAL CONSIDERATIONS
An exception handler must follow the same general guidelines as other kinds of asynchronous software. For instance, it cannot cause memory to be purged or compacted, and it should not use any handles that are not locked. See Inside Macintosh: Processes for a description of the restrictions applying to interrupt tasks and other asynchronous software.
An exception handler must be reentrant if it can itself generate exceptions.
SEE ALSO
See “Writing an Exception Handler” on page 4-7 for more information about writing an exception handler.
32-bit cleanSaid of an application (or other software) that is able to run in an environment where all 32 bits of a memory address are used for addressing.
680x0See 680x0 microprocessor.
680x0 applicationAn application that contains code only for a 680x0 microprocessor. See also fat application and PowerPC application.
680x0-based Macintosh computerAny computer containing a 680x0 central processing unit that runs Macintosh system software.
See also PowerPC processor-based
Macintosh computer.
680x0 compilerAny compiler that produces code that can execute on a 680x0. See also PowerPC compiler.
680x0 context blockA block of data used by the 68LC040 Emulator to maintain information across mode switches. The structure of this block of data is private.
680x0 microprocessorAny member of the Motorola 68000 family of microprocessors.
680x0 softwareAny software (that is, applica-
tion, extension, driver, or other executable code) that consists of code only for a 680x0 micro-
processor. See also 680x0 application.
68LC040 EmulatorThe part of the system software that allows 680x0 applications and other 680x0 software to execute on PowerPC processor-
based Macintosh computers. See also Mixed Mode Manager.
A5 worldAn area of memory in a 680x0 application’s partition that contains the QuickDraw global variables, the application global variables, the application parameters,
and the jump table—all of which are accessed through the A5 register. See also mini-A5 world.
accelerated resourceAn executable resource consisting of a routine descriptor and PowerPC code that specifically models the behavior of a 680x0 stand-alone code resource. Compare private resource.
accelerated system software routineAny Toolbox or Operating System routine that has been rewritten as PowerPC code.
A-line instructionAn instruction that is not recognized by a 680x0 microprocessor and that the Trap Manager uses to execute Toolbox and Operating System routines. The first word of an A-line instruction is binary 1010 (hexadecimal A).
ANSI C language dialectThe C programming language dialect that adheres to the language defined by the document American National Standard for Information Systems—Programming Language—C, ANSI X3.159-1989.
applicationA file of type 'APPL' that can be launched by the Process Manager. See also 680x0 application and PowerPC application.
application extensionA fragment containing code and data (such as a data-conversion filter, tool, and so forth) that extends the capabilities of an application.
application global variablesA set of variables stored in the application partition that are global to the application.
application heapAn area of memory in the application heap zone in which memory is dynamically allocated and released on demand.
application parametersThirty-two bytes of memory in the A5 world of a 680x0 application that are reserved for system use. The first long word is the address of the first QuickDraw global variable.
application partitionA partition of memory reserved for use by an application. The applica-
tion partition consists of free space, along with the application’s heap and stack. The application partition for a 680x0 application also contains an A5 world.
A-trapSee A-line instruction.
backing-store fileThe file in which the Virtual Memory Manager stores the contents of unneeded pages of memory. See also file mapping and paging file.
backing volumeSee paging device.
bindTo find the referent of an import and place its address in a fragment’s table of contents.
bus sizingSee dynamic bus sizing.
byte smearingThe ability of certain members of the 680x0 family of microprocessors to duplicate byte- and word-sized data across all
32 bits of the data bus.
cacheSee data cache or instruction cache.
callback routineA routine that is executed as part of the operation of some other routine.
calleeA routine that is called by some routine.
callerA routine that calls some routine.
calling conventionsA set of conventions that describe the manner in which a particular routine is executed. A routine’s calling conventions specify where parameters and function results are passed. For a stack-based routine, the calling conventions determine the structure of the routine’s stack frame.
code fragmentSee fragment.
code fragment information recordA part of a code fragment resource that provides information about a specific code fragment. There can be more than one code fragment information record in a code fragment resource.
Code Fragment LoaderThe part of the Macintosh system software that reads containers and loads the fragments they contain into memory. Currently, the application programming interface to the Code Fragment Loader is private. See also Code Fragment Manager.
Code Fragment ManagerThe part of the Macintosh system software that loads fragments into memory and prepares them for execution. See also Code Fragment Loader and fragment.
code fragment resourceA resource of type 'cfrg' that identifies the instruction set architec-
ture, location, size, and name of an application or import library, as well as version information for import libraries. See also code fragment informa-
tion record.
code patchSee patch.
code resourceSee executable resource.
code sectionA section of a fragment that contains executable code. See also data section.
code typeSee instruction set architecture.
compile-time librarySee definition version.
Condition Register (CR)A register in the PowerPC processor that holds the result of certain integer and floating-point operations.
connectionA link between two fragments.
connection IDA reference number that uniquely identifies a connection. Defined by
the ConnectionID data type.
containerThe storage for a fragment. A container is a contiguous chunk of storage that holds a fragment and information describing the location of the parts of the fragment and the format of the container.
contextThe block of static data (global variables, static variables, and function pointers) associated with one loading of an import library. Each application is loaded into its own context.
context blockSee 680x0 context block.
CRSee Condition Register.
cross-mode callA call to code that is in a different instruction set architecture from the caller’s. See also explicit cross-mode call and implicit cross-mode call.
cross-TOC callA call to code that is in a different fragment from the caller’s. A cross-TOC call requires that the Table of Contents Register be changed to the callee’s TOC value.
dangling pointerA pointer that no longer points to the correct memory address.
data cacheAn area of memory internal to some microprocessors (for example, the MC68030 and MC68040 microprocessors) that holds recently accessed data. See also instruction cache.
data sectionA section of a fragment that contains its static data, including the fragment’s table of contents. See also code section.
de facto C++ standardThe current C++ language definition described in the working paper American National Standard for Information Systems—Programming Language—C++, ANSI X3J16.
definition functionA function that defines the appearance and behavior of some user interface element (for example, a control, list, or window). See also stub definition function.
definition resourceA resource that contains a definition function. See also stub definition resource.
definition versionThe version of an import library used by the linker to resolve imports in the application (or other fragment) being linked. The definition version defines the external programming interface and data format of the library. Compare implementation version.
disk location recordA data structure that provides information about the location of a fragment in the data fork of a file on disk. Defined by the DiskFragment data type.
drop-inSee application extension.
dynamically linked librarySee import library.
dynamic bus sizingThe ability of certain members of the 680x0 family of microprocessors to allow I/O devices with 8-bit and 16-bit data paths to work with the processor’s 32-bit data bus.
emulated applicationAn application whose executable code is not in the instruction set architecture of the CPU. An emulated application relies on an emulator to translate its code into that instruction set. See also 680x0 application.
emulationThe process by which a micro-
processor is able to execute code in an instruction set different from its native instruction set. See also 68LC040 Emulator.
emulation environmentThe 680x0-compatible environment on PowerPC processor-based Macintosh computers provided by the 68LC040 Emulator and the Mixed Mode Manager.
emulatorSee 68LC040 Emulator.
epilogA standard piece of code at the end of a routine that restores any nonvolatile registers saved by the routine’s prolog, tears down the routine’s stack frame, and returns to the caller. See also prolog.
exceptionAn error or other special condition detected by the microprocessor in the course of program execution.
exception codeA constant that indicates which kind of exception has occurred.
exception handlerAny routine that handles exceptions.
exception information recordA data structure that contains information about an exception, such as the exception kind, the machine state at the time of the exception, and so forth. Defined by the ExceptionInformation data type.
Exception ManagerThe part of the Macintosh system software that handles exceptions that occur during the execution of PowerPC applica-
tions or other software.
exception stack frameA block of data placed on the stack automatically by the processor when an exception occurs.
executable resourceAny resource that contains executable code. See also accelerated resource and private resource.
explicit cross-mode callA call to code that is in a different instruction set architecture from the caller’s, caused by the caller explicitly calling the CallUniversalProc function.
exportTo make a symbol externally visible. Also, a synonym for exported symbol.
exported symbolA symbol in a fragment that is visible to some other fragments. See also import library and imported symbol.
Extended Common Object File Format (XCOFF)A format of executable file generated by some PowerPC compilers. See also Preferred Executable Format.
extensionSee application extension and system extension.
external codeAny block of executable code that is not directly contained in an application or other software.
fake handleA handle that was not created by the Memory Manager but is passed to some Memory Manager routine.
fake pointerA pointer that was not created by the Memory Manager but is passed to some Memory Manager routine.
fatContaining or describing code of multiple instruction sets.
fat applicationAn application that contains code of two or more instruction sets. See also 680x0 application and PowerPC application.
fat binaryAny piece of executable code (application, code resource, trap, or trap patch) that contains code of multiple instruction sets. See also fat application, fat patch, fat resource, and fat trap.
fat patchA trap patch that contains executable code in two or more instruction sets.
fat resourceA code-bearing resource that contains executable code in two or more instruction sets. A fat resource begins with a
fat routine descriptor.
fat routine descriptorA routine descriptor that contains routine records for a routine’s code in two or more instruction sets.
fat trapA system software routine that is implemented in two or more instruction sets. In general, the Operating System selects the trap implementation that avoids mode switches. See also split trap.
file and directory registryA list of files and directories that the Code Fragment Manager should search when looking for import libraries. See also ROM registry.
file mappingThe process of using a file’s data fork as the virtual memory paging file.
Floating-Point Status and Control Register (FPSCR)A 32-bit PowerPC register used to store the floating-point environment.
FPSee frame pointer.
FPSCRSee Floating-Point Status and Control Register.
fragmentAny block of executable PowerPC code and its associated data.
fragment initialization blockA parameter block passed to a fragment’s initialization routine that contains information about the fragment. Defined by the InitBlock data type.
fragment location recordA data structure that provides information about the location of a fragment. Defined by the FragmentLocator data type.
frameSee stack frame or switch frame.
frame pointer (FP)A pointer to the beginning of a stack frame. See also stack pointer.
function prototypeA declaration of the types of parameters expected by a function and of the type of the result it returns. ANSI C requires function prototypes for all functions you define.
global instantiationThe method of allocating an import library’s static data in which only one copy of that data is created regardless of how many connections to the library are made. See also per-context instantiation and per-load instantiation.
global variablesSee application global variables, QuickDraw global variables, and system global variables.
glue routineA run-time library routine, usually provided by the development environment, that provides the subroutine linkage between high-
level language code and a system routine with an interface protocol different from that of the high-level language.
hard importAn imported symbol that must be defined at run time and whose corresponding code or data must therefore be available in an import library on the host machine. Compare import and soft import.
head patchA patch that, upon completion, jumps to the next patch in the patch daisy chain. Compare tail patch.
heapAn area of memory in which space
is dynamically allocated and released on
demand, using the Memory Manager. See also
application heap.
hybrid environmentSee mixed environment.
implementation versionThe version of an import library that is connected at load time to the application (or other fragment) being loaded. The implementation version provides the actual executable code and data exported by the library. Compare definition version.
implicit cross-mode callA call to code that is in a different instruction set architecture from
the caller’s, caused by the caller executing a routine descriptor.
importTo refer to a symbol located in some other fragment. Also, a synonym for
imported symbol.
imported symbolA symbol in a fragment that references code or data exported by some other fragment. See also exported symbol and
import library.
import libraryA shared library that is auto-
matically loaded at run time by the Code Fragment Manager.
initialization blockSee fragment initializa-
tion block.
initialization routineA function contained in a fragment that is executed immediately after the fragment has been loaded and prepared. See also termination routine.
input/output (I/O)The parts of a computer system that transfer data to or from
peripheral devices.
instantiationSee global instantiation, per-context instantiation, and per-load instantiation.
instruction cacheAn area of memory internal to some microprocessors (for example, the MC68020, MC68030, and MC68040 micro-
processors) that holds recently used instructions. See also data cache.
instruction set architectureThe set of instruc-
tions meaningful to a particular microprocessor or to a family of microprocessors.
interface filesSee universal interface files.
interruptSee exception.
I/OSee input/output.
jump tableAn area of memory in a 680x0 application’s A5 world that contains one entry for every externally referenced routine in every code segment of the application. The jump table is the means by which the loading and unloading of segments are implemented.
KBAbbreviation for kilobyte. A kilobyte is 1024 bytes.
leaf procedureA routine that calls no other routines.
librarySee import library.
library directoryA directory used by an application or other fragment to store import libraries used by that application or fragment.
An application’s library directory is specified
in the application’s code fragment resource.
linkage areaThe area in a PowerPC stack frame that holds the caller’s RTOC value and saved values of the Count Register and Link Register. See also parameter area.
Link Register (LR)A register in the PowerPC processor that holds the return address of the currently executing routine.
load directoryThe directory that contains a fragment being loaded into memory and prepared for execution.
local variableA variable allocated and used only within the current procedure.
location recordSee fragment location record.
lock(1) To prevent a relocatable block from being moved during heap compaction. (2) To temporarily prevent a range of physical memory from being paged out or moved by the Virtual Memory Manager.
low-memory global variablesSee system global variables.
LRSee Link Register.
machine information recordA data structure that contains information about the state of the machine at the time an exception occurs. Defined by the MachineInformation data type.
Macintosh Operating SystemThe part of Macintosh system software that manages basic low-level operations such as file reading and writing, memory allocation and deallocation, process execution, and interrupt handling.
Macintosh Programmer’s Workshop (MPW)
A software development system for the Macintosh family of computers provided
by Apple Computer.
Macintosh system software A collection of routines that you can use to simplify your development of Macintosh applications. See
also Macintosh Toolbox and Macintosh Operating System.
Macintosh ToolboxThe part of the Macintosh system software that allows you to implement the standard Macintosh user interface in your application or other software.
Macintosh User Interface Toolbox See Macintosh Toolbox.
main routineA function contained in a fragment whose use depends on the kind of fragment it is in. For applications, the main routine is the usual entry point. See also
main symbol.
main symbolA symbol whose use depends on the kind of fragment it is in. For applications, the main symbol refers to the fragment’s main routine. See also main routine.
MBAbbreviation for megabyte. A megabyte is 1024 kilobytes, or 1,048,576 bytes.
memory location recordA data structure
that provides information about the location
of a fragment in memory. Defined by the MemFragment data type.
memory management unit (MMU)Any component that performs address mapping in a Macintosh computer. In Macintosh II computers, it is either the Address Management Unit (AMU) or the Paged Memory Management Unit (PMMU). The MMU function is built into the MC68030 and MC68040 microprocessors.
Memory ManagerThe part of the Operating System that dynamically allocates and releases memory space in the heap.
mini-A5 worldAn area of memory created and maintained by the Process Manager for a native PowerPC application. A native application’s mini-A5 world contains a pointer to the applica-
tion’s QuickDraw global variables. See also
A5 world.
mixed environmentA process execution environment that supports applications and other software written in more than one instruction set.
Mixed Mode ManagerThe part of the Macintosh system software that manages the mixed-mode architecture of PowerPC processor-
based computers running 680x0-based code (including system software, applications, and stand-alone code modules).
MMUSee memory management unit.
mode switchThe process of switching the execution context between the CPU’s native context and an emulator (for example, the 68LC040 Emulator). See also switch frame.
MPWSee Macintosh Programmer’s Workshop.
nanokernelThe lowest-level part of the system software for PowerPC processor-based Macintosh computers.
native applicationAn application whose executable code is in the instruction set architecture of the CPU. See also PowerPC application.
nonvolatile registerA register whose contents must be preserved across subroutine calls. If a routine changes the value of a nonvolatile register, it must save the old value on the stack before changing the register and restore that value before returning. See also saved registers area and volatile register.
opcodeSee operation code.
Operating SystemSee Macintosh Operating System.
operation codeThe part of a machine instruction that encodes the operation to be performed. Often shortened to opcode.
pageThe basic unit of memory used in
virtual memory.
paged memory management unit (PMMU)The Motorola MC68851 chip, used in the Macintosh II computer to perform logical-to-physical address translation and paged memory management.
page faultA special kind of bus error caused by an attempt to access data in a page of memory that is not currently resident in RAM.
pagingThe process of moving data between physical memory and a paging file.
paging deviceA volume that contains the backing-store file or a paging file.
paging fileA file used to store unneeded pages of memory. See also backing-store file.
parameter areaThe area in a PowerPC stack frame that holds the parameters for any routines called by a given routine. See also linkage area.
partitionA contiguous block of memory reserved for use by the Operating System or by an application. See also application partition and system partition.
patchAny code used to repair or augment an existing piece of code. In the context of Macintosh system software, a patch repairs or augments a trap. See also head patch and tail patch.
PCSee program counter.
PC-relativeA form of instruction addressing
in which the destination instruction is some number of instructions before or after the
current instruction.
PEFSee Preferred Executable Format.
per-context instantiationThe method of allocating an import library’s static data in which one copy of that data is created for each separate application using the library. Using this method, a single application may have only one copy of the static data. See also global instantiation and per-load instantiation.
per-load instantiationThe method of allocating an extension’s static data in which one copy of that data is created for each separate connection to the extension. Using this method, a single client may have multiple copies of the static data. See also global instantiation and per-context instantiation.
PMMUSee paged memory management unit.
PowerPCSee PowerPC microprocessor.
PowerPC applicationAn application that contains code only for a PowerPC microprocessor.
See also 680x0 application and fat application.
PowerPC compilerAny compiler that produces code that can execute on a PowerPC. See also 680x0 compiler.
PowerPC microprocessorAny member of the family of PowerPC microprocessors. The MPC601 processor is the first PowerPC CPU.
PowerPC NumericsThe floating-point environment on PowerPC processor-based Macintosh computers. This environment provides floating-point data types and arithmetic operations, plus some advanced numerical functions (such as logarithmic and trigonometric functions). See also Standard Apple Numerics Environment.
PowerPC processor-based Macintosh computerAny computer containing a PowerPC central processing unit that runs Macintosh system software. See also 680x0-based Macintosh computer.
PowerPC softwareAny software (that is, application, extension, driver, or other executable code) that consists of code only for a PowerPC microprocessor. See also PowerPC application.
Preferred Executable Format (PEF)The format of executable files used for PowerPC applications and other software running on Macintosh computers. See also Extended Common Object File Format.
prepareTo resolve imports in a fragment to exports in some import library.
private resourceAny executable resource whose behavior is defined by your application (or other kind of software) alone. Compare accelerated resource.
procedure informationA long word that encodes information about a routine’s calling conventions, the sizes and locations of the routine’s parameters, and the size and
location of the routine’s result. Defined by the ProcInfoType data type.
procedure pointerA reference generated by a compiler when taking the address of a routine. On 680x0-based Macintosh computers, a procedure pointer is the address of the routine’s executable code (and is defined by the ProcPtr data type). On PowerPC processor-based Macintosh computers, a procedure pointer is the address of the routine’s transition vector.
Process ManagerThe part of the Macintosh Operating System that provides a cooperative multitasking environment by controlling access to shared resources and managing the scheduling, execution, and termination of applications.
processor cacheSee data cache or
instruction cache.
ProcInfoTypeSee procedure information.
ProcPtrSee procedure pointer.
program counter (PC)A register in the CPU that contains a pointer to the memory location of the next instruction to be executed.
prologA standard piece of code at the begin-
ning of a routine that sets up the routine’s stack frame and saves any nonvolatile registers used by the routine. See also epilog.
prototypeSee function prototype.
QuickDraw global variablesA set of variables stored in a 680x0 application’s A5 world that contain information used by QuickDraw.
reduced instruction set computer (RISC)A microprocessor in which all machine instructions are uniformly formatted and are processed through the same steps. See also PowerPC microprocessor.
Red ZoneThe area of memory immediately above the address pointed to by the stack pointer. The Red Zone is reserved for temporary use by a function’s prolog and as an area to store a leaf routine’s nonvolatile registers.
reentrant exception handlerAn exception handler that can be interrupted while servicing an exception, then service a new exception, and then complete servicing the original exception.
register-based routineA routine that receives its parameters and returns its results, if any, in registers. See also stack-based routine.
RISCSee reduced instruction set computer.
ROM registryA list of the import libraries that are stored in the ROM of a Macintosh computer. See also file and directory registry.
routine descriptorA data structure used by the Mixed Mode Manager to execute a routine. A routine descriptor contains one or more routine records. Defined by the RoutineDescriptor data type.
routine recordA data structure that contains information about a particular routine. A routine record specifies, among other things, a routine’s instruction set architecture, the number and
size of its parameters, its calling conventions,
and its location in memory. Defined by the RoutineRecord data type.
RTOCSee Table of Contents Register.
run-time environmentThe execution environment provided by the Process Manager and other system software services. The run-time environment dictates how executable code is loaded into memory, where data is stored, and how functions call other functions and system software routines.
run-time librarySee implementation version.
SANESee Standard Apple Numerics Environment.
saved registers areaThe area in a PowerPC stack frame that holds the saved values of the nonvolatile general-purpose and floating-
point registers.
sectionA region of memory occupied by part of a loaded fragment. When a fragment is loaded, it is divided into a code section and one or more copies of the data section. See also code section and data section.
segment One of several logical divisions of the code of a 680x0 application. Not all segments need to be in memory at the same time.
segment location recordA data structure that provides information about the location of a fragment in the resource fork of a file on disk. Defined by the SegmentedFragment data type.
Segment Manager The part of the Macintosh Operating System that loads and unloads the code segments of a 680x0 application into and out of memory.
selector-based trapA system software routine that is called by passing a selector code to a single trap macro.
shared libraryA fragment that exports functions and global variables to other fragments. A shared library is used to resolve imports during linking and also during the loading and preparation of some other fragment. A shared library can be stored in a file of type 'shlb'. See also import library.
smearingSee byte smearing.
soft importAn imported symbol whose corre-
sponding code or data might not be available in any import library on the host machine and which is therefore undefined at run time. Compare hard import and import.
SPSee stack pointer.
split trapA system software routine that is implemented as 680x0 code in ROM and as PowerPC code in an import library. Because the PowerPC code is contained directly in the import library, you cannot patch the PowerPC portion of a split trap. Compare fat trap.
stackAn area of memory in the application partition that is used for temporary storage of data during the operation of an application or other software.
stack-based routineA routine that receives its parameters and returns its results, if any, on the stack. See also register-based routine.
stack frameThe area of the stack used by a routine for its parameters, return address, local variables, and temporary storage.
stack pointer (SP)A pointer to the top of the stack. See also frame pointer.
stale instructionAn instruction in the micro-
processor’s instruction cache whose corre-
sponding values in RAM have changed. You might need to flush the instruction cache to avoid using stale instructions.
Standard Apple Numerics Environment (SANE) The floating-point environment on 680x0-based Macintosh computers and on Apple II computers. This environment provides floating-point data types and arithmetic operations, plus some advanced numerical functions (such as logarith-
mic and trigonometric functions). See also PowerPC Numerics.
static dataThe variables and other data that persist between calls to a particular function
or fragment.
stub definition functionCode that dispatches to a definition function contained elsewhere. See also definition function.
stub definition resourceAn executable resource that contains a stub definition function. See also definition resource.
subroutine linkageThe mechanism by which one routine calls another, possibly passing arguments and receiving a function result.
switchSee mode switch.
switch frameA stack frame, created by the Mixed Mode Manager during a mode switch, that contains information about the routine to be executed, the state of various registers, and the address of the previous frame.
symbolA name for a discrete element of code or data in a fragment.
system extensionA file of type 'INIT' that contains executable code. System extensions are loaded into memory at system startup time.
system global variablesA collection of global variables stored in the system partition.
system heapAn area of memory in the
system partition reserved for use by the Operating System.
system partitionA partition of memory reserved for use by the Operating System.
table of contents (TOC)An area of static data in a fragment that contains a pointer to each routine or data item that is imported from some other fragment, as well as pointers to the fragment’s own static data.
Table of Contents Register (RTOC)A processor register that points to the table of contents of the fragment containing the code currently being executed. On the PowerPC processor, the general-purpose register 2 is dedicated to serve as the RTOC.
tail patchA patch that invokes the next patch in the patch daisy chain as a subroutine, guaranteeing that the tail patch regains control after the execution of all subsequent patches. Compare head patch.
temporary memoryMemory allocated outside an application partition that may be available for occasional short-term use.
termination routineA function contained in a fragment that is executed just before the fragment is unloaded. See also initialization routine.
TOCSee table of contents.
toolSee application extension.
transition vectorAn area of static data in a fragment that describes the entry point and TOC address of a routine. See also procedure pointer.
trapAny of a large set of Macintosh system software routines accessed via A-line instructions. See also split trap.
trap dispatcherThe exception handler that deals with the occurrence of A-line instructions, providing the subroutine linkage between the A-line instruction and Macintosh system code.
trap dispatch tableA table of entry points to Macintosh system routines that are invoked with A-line instructions.
Trap ManagerThe part of the Macintosh Operating System that provides the subroutine linkage to most Macintosh system soft-
ware routines.
trap patch See patch.
universal interface filesA set of interface files that you can use with both 680x0 compilers and PowerPC compilers.
universal procedure pointerA 680x0 procedure pointer or the address of a
routine descriptor.
VBLSee vertical retrace interrupt.
VBL taskA task executed during a vertical retrace interrupt.
vertical retrace interruptAn interrupt generated by the video circuitry each time the electron beam of a monitor’s display tube returns from the lower-right corner of the screen to the upper-left corner.
virtual memoryAddressable memory beyond the limits of the available physical RAM. The Operating System extends the logical address space by allowing unused code and data to be stored on a secondary storage device instead of in physical RAM.
Virtual Memory ManagerThe part of the Operating System that provides virtual memory.
volatile registerA register whose contents need not be preserved across subroutine calls. See also nonvolatile register.
weak importSee soft import.
XCOFFSee Extended Common Object File Format.
Index
Numerals
32-bit clean1-4
680x0 applications1-6 to 1-12
porting to PowerPC1-15 to 1-19, 1-31 to 1-34, 1-57 to 1-65, 1-68 to 1-72, 2-21 to 2-26, 3-12 to 3-13, 4-6 to 4-9
structure of1-32
680x0 compatibility issues. See 68LC040 Emulator
680x0 context blocks1-8, 1-59
680x0 registers. See also A0 register; A5 register;
This Apple manual was written, edited, and composed on a desktop publishing system using Apple Macintosh computers and FrameMaker software. Proof pages were created on an Apple LaserWriter IINTX printer. Final page negatives were output directly from text files on an Optrotech SPrint 220 imagesetter. Line art was created using Adobe™ Illustrator. PostScript™, the page-description language for the LaserWriter, was developed by Adobe Systems Incorporated.
Text type is Palatino® and display type is Helvetica®. Bullets are ITC Zapf Dingbats®. Some elements, such as program listings, are set in Apple Courier.
WRITER
Tim Monroe
DEVELOPMENTAL EDITOR
Jeanne Woodward
ILLUSTRATOR
Shawn Morningstar
ART DIRECTOR
Betty Gee
PROJECT LEADER
Patricia Eastman
COVER DESIGNER
Barbara Smyth
Special thanks to Richard Clark, Erik Eidt, Dave Falkenburg, Bruce Jones, Alan Lillich, Mikey McDougall, Dave Radcliffe, Brian Topping, and Eric Traut.
Acknowledgments to Eric Anderson, Scott Boyd, Joanna Bujes, Jeff Crawford, Gary Davidian, Peri Frantz, Miki Lee, Wayne Meretsky, Brian Strull,
Beverly Zegarski, and the entire Inside Macintosh team.
\ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4í ∫◊ , Palatino
. ° d ONLN dˇˇ (ô ∫ Addison-W Ñ@ ° d ONLN dˇˇ )4esley Publishing Company
° d ONLN dˇˇ (´ ∫Reading, Massachusetts À† ° d ONLN dˇˇ )hMenlo Park, California ì‡ ° d ONLN dˇˇ )dNew ˆ∞ ° d ONLN dˇˇ )Y # ° d ONLN dˇˇ )ork ° d ONLN dˇˇ (∑ ∫Don Mills, Ontario c ° d ONLN dˇˇ )TW è† ° d ONLN dˇˇ )okingham, England @ ° d ONLN dˇˇ )XAmster Ü ° d ONLN dˇˇ ) dam wp ° d ONLN dˇˇ )Bonn ° d ONLN dˇˇ (√ ∫Sydney H ° d ONLN dˇˇ )'Singapor ° d ONLN dˇˇ )$e e∞ ° d ONLN dˇˇ )
T ° d ONLN dˇˇ )okyo ÏP ° d ONLN dˇˇ ) Madrid – ° d ONLN dˇˇ )(San Juan ° d ONLN dˇˇ (œ ∫Paris l¿ ° d ONLN dˇˇ ) Seoul k` ° d ONLN dˇˇ ) Milan ËÄ ° d ONLN dˇˇ ) Mexico City ° d ONLN dˇˇ ):T »Ä ° d ONLN dˇˇ )aipei
accurate. ªÄ ° d ONLN d˛* K3 { )!Apple is not r ° d ONLN d * |3 Ø )1esponsible for ° d ONLN d3 *< w (: *printing or clerical err Ä ° d ONLN d33 x< Ñ )Nors. ° d ONLN d8@ *I f (G *Apple Computer >Ä ° d ONLN dF@ fI v )<, Inc. ° d ONLN dMI *R ^ (P *20525 Mariani >Ä ° d ONLN d[I ^R d )4A ªÄ ° d ONLN d\I cR x )venue ° d ONLN dbR *[ ^ (Y *
Cupertino, CA 6Ä ° d ONLN doR ^[ t )4 95014 ° d ONLN dv[ *d W (b * 408-996-1010 ° d ONLN dÉh *q Q *
and QuickT ÚÄ ° d ONLN dò≤ Sª i ))ime ar 0 ° d ONLN dû≤ jª £ )e trademarks of ° d ONLN dƪ *ƒ f (¬ *Apple Computer >Ä ° d ONLN dºª fƒ v )<, Inc. ° d ONLN d√Δ *œ • (Õ *#Adobe Illustrator and PostScript ar Ä ° d ONLN dÊΔ ¶œ ´ )|e ° d ONLN dËœ *ÿ ] (÷ *trademarks of …Ä ° d ONLN dˆœ ]ÿ ï )3Adobe Systems ° d ONLN dÿ *· í (fl * Incorporated, which may be r >Ä ° d ONLN d ÿ ì· ™ )iegister ¥ ° d ONLN d'ÿ ™· ¥ )ed ° d ONLN d*· *Í z (Ë *in certain jurisdictions. ° d ONLN dDÏ *ı ™ * $America Online is a service mark of ° d ONLN dhı *˛ ¢ * Quantum Computer Services, Inc. ° d ONLN dà * U * Classic is a r ÂÄ ° d ONLN dñ U l )+egister [ ° d ONLN dù m û )
ed trademark ° d ONLN d™ * Q ( * licensed to ¸Ä ° d ONLN d∂ Q ç )'Apple Computer ª ° d ONLN dƒ ç ù )<, Inc. ° d ONLN dÀ * k ( *CompuServe is a r ÉÄ ° d ONLN d‹ k Ç )Aegister ˘ ° d ONLN d„ Ç ß ) ed service ° d ONLN dÓ *& Ü ($ *mark of CompuServe, Inc. 4 ^ ….Y ° d ONLN d \ … e ( c …FrameMaker is a r øÄ ° d ONLN d \ e )@egister 5 ° d ONLN d \! eR )
ed trademark ° d ONLN d, e … n Ô ( l …
of Frame T 4 ° d ONLN d6 e Ô nC )&echnology Corporation. ° d ONLN dM p … y" ( w …Helvetica and Palatino ar ÷Ä ° d ONLN df p" y* )Ye r ∞ ° d ONLN di p+ yB ) egister %Ä ° d ONLN dp pC yM )ed ° d ONLN ds y … ÇA ( Ä … trademarks of Linotype Company & ° d ONLN dë yA ÇC )x. ° d ONLN dì Ñ … ç? ( ã …#Internet is a trademark of Digital ° d ONLN d∂ ç … ñ * Equipment Corporation. ° d ONLN dÕ ò … ° * ITC Zapf Dingbats is a r ]Ä ° d ONLN d ò °5 )Uegister ” ° d ONLN dÏ ò5 °? )ed ° d ONLN dÔ ° … ™- ( ® … trademark of International T Δ ° d ONLN d °- ™J )dypeface ° d ONLN d ™ … ≥ ˆ ( ± … Corporation. ° d ONLN d µ … æ fl * Motor mÄ ° d ONLN d% µ fl æ ¸ )
ola is a r ‹ ° d ONLN d/ µ ¸ æ ) egister QÄ ° d ONLN d6 µ æN )ed trademark of ° d ONLN dF æ … « fl ( ≈ …Motor mÄ ° d ONLN dK æ fl « )ola Corporation. ° d ONLN d\ … … “ Ÿ ( – …Optr 9Ä ° d ONLN d` … ⁄ “O )!otech is a trademark of Orbotech ° d ONLN dÅ “ … € ˆ ( Ÿ … Corporation. ° d ONLN dé › … Ê* * PowerPC is a trademark of ° d ONLN d® Ê … Ô= * International Business Machines ° d ONLN d» Ô … ¯ ˆ * Corporation. ° d ONLN d’ ˙ …O * #THINK C is a trademark of Symantec ° d ONLN d¯ … ˆ * Corporation. ° d ONLN d … * UNIX is a r #Ä ° d ONLN d Ò )(egister ô ° d ONLN dB )ed trademark of ° d ONLN d' … 8 ( … UNIX System Laboratories, Inc. ° d ONLN dF$ …-X *
'Simultaneously published in the United ° d ONLN dm- …6 * States and Canada. 4 ^h.¯
° d ONLN dÄ ]h eê ( ch LIMITED W ° d ONLN dâ ]ê e‹ )(ARRANTY ON MEDIA öp ° d ONLN dô ]‹ e )L AND ° d ONLN dû fh nû ( lh REPLACEMENT ° d ONLN d™ sh {u *
ALL _0 ° d ONLN d≠ sv {ü )
IMPLIED W Yê ° d ONLN d∑ sü {Ï ))ARRANTIES ON THIS ° d ONLN d… |h Ñ€ ( ÇhMANUAL, INCLUDING IMPLIED ° d ONLN d„ Öh ço * W fl ° d ONLN d‰ Ön ç— )ARRANTIES OF MERCHANT d ° d ONLN d˘ Ö— çÔ )cABILITY ° d ONLN d éh ñ∞ ( îhAND FITNESS FOR A Ê∞ ° d ONLN d é∞ ñ∂ )H P h¿ ° d ONLN d é∂ ñ¿ )AR ÜP ° d ONLN d é¿ ñ‚ )
PURCHASE ° d ONLN d Å ≤h ∫™ ( ∏hOF THIS PRODUCT æ` ° d ONLN d ê ≤™ ∫´ )B. ° d ONLN d í øh «· ( ≈h$Even though Apple has reviewed this ° d ONLN d ∂ »h –à * manual, APPLE MAKES NO W a@ ° d ONLN d Œ »Ã –Ò )dARRANTY ° d ONLN d ÷ —h Ÿû ( ◊h OR REPRESENT {¿ ° d ONLN d ‚ —û Ÿ£ )6A I ° d ONLN d „ —£ Ÿˆ )TION, EITHER EXPRESS ° d ONLN d ¯ ⁄h ‚Ó ( ‡h!OR IMPLIED, WITH RESPECT TO THIS ° d ONLN d
„h Ϊ * MANUAL, ITS QUALITY f∞ ° d ONLN d
, „ª ÎÁ )S
, ACCURACY õÄ ° d ONLN d
6 „Á ÎÍ ),, ° d ONLN d
8 Ïh Ùì ( ÚhMERCHANT ° d ONLN d
@ Ïì Ù∞ )+ABILITY ≠p ° d ONLN d
G ÏØ ÙÙ ) , OR FITNESS FOR A [† ° d ONLN d
Y Ïı Ùˆ )F ° d ONLN d
Z ıh ˝l ( ˚hP B ° d ONLN d
[ ıl ˝v )AR _† ° d ONLN d
] ıv ˝Œ )
TICULAR PURPOSE. AS A Ñê ° d ONLN d
r ıŒ ˝Á )X RESUL ‡ ° d ONLN d
x ıÁ ˝Î )T † ° d ONLN d
y ıÎ ˝Ó ), ° d ONLN d
{ ˛hú (h THIS MANUAL ° d ONLN d
Ü ˛ùÌ )5 IS SOLD “AS IS,” AND ° d ONLN d
úh˜ (
h!YOU, THE PURCHASER, ARE ASSUMING ° d ONLN d
Ωh * "THE ENTIRE RISK AS TO ITS QUALITY ° d ONLN d
flh!§ * AND ACCURACY 0 ° d ONLN d
Χ!• )<. ° d ONLN d
Ì&h.¨ (,hIN NO EVENT WILL ùp ° d ONLN d
˝&¨.Ï )D APPLE BE LIABLE ° d ONLN d /h7î (5h
FOR DIRECT ˇ@ ° d ONLN d /ì7∫ )+
, INDIRECT ° d ONLN d "/ª7‡ )( , SPECIAL, ° d ONLN d -8h@å (>hINCIDENT ÃÄ ° d ONLN d 58å@Â )$AL, OR CONSEQUENTIAL K ° d ONLN d I8Ê@Á )Z ° d ONLN d JAhIß (Gh
DAMAGES RESUL )– ° d ONLN d WAßIÂ )?TING FROM ANY ° d ONLN d eJhR„ (Ph DEFECT OR INACCURACY IN THIS ° d ONLN d ÇSh[˜ * +MANUAL, even if advised of the possibility ° d ONLN d ≠\hdû * of such damages. ° d ONLN d æihq *
THE W e† ° d ONLN d √iqÓ )ARRANTY AND REMEDIES SET ° d ONLN d ‹rhzv (xhFOR Â ° d ONLN d flrvzÎ )TH ABOVE ARE EXCLUSIVE AND ° d ONLN d ˚{hÉû (ÅhIN LIEU OF ALL ü0 ° d ONLN d {ûÉ’ )6
OTHERS, ORAL J¿ ° d ONLN d {÷ɉ )8 OR ° d ONLN d ÑhåÈ (äh WRITTEN, EXPRESS OR IMPLIED. No ° d ONLN d :çhïë * Apple dealer Ü0 ° d ONLN d FçëïŸ )), agent, or employee is ° d ONLN d ^ñhû (úh authorized to make any modifi ° d ONLN d {ñ û‡ )bcation, ° d ONLN d Éühß‚ (•h'extension, or addition to this warranty Û` ° d ONLN d ™ü·ß‚ )y. ° d ONLN d ¨¨h¥Ì (≤h*Some states do not allow the exclusion or ° d ONLN d ÷µhΩÙ * .limitation of implied warranties or liability ° d ONLN d
æhΔÎ * )for incidental or consequential damages, ° d ONLN d
.«hœÍ * )so the above limitation or exclusion may ° d ONLN d
X–hÿÓ * *not apply to you. This warranty gives you ° d ONLN d
ÇŸh·| * specifi ¿ ° d ONLN d
âŸ}·Û )&c legal rights, and you may also have ° d ONLN d
Ø‚hÍÓ (Ëh,other rights which vary from state to state. 4d *¬ ∫
° d ONLN d
‹b *k n (i *ISBN 0-201-40727-2 ° d ONLN d
Ôk *t k * 1 2 3 4 5 6 7 8 9-CR ‚Ä ° d ONLN dk kt s )AW r ° d ONLN dk st ù ) -9897969594 ° d ONLN dt *} l ({ *First Printing, Febr C ° d ONLN d$t m} è )C uary 1994 4d …¬¯ ° d ONLN d.b …kÖ (i …2Library of Congress Cataloging-in-Publication Data ° d ONLN dap …yb *(Inside Macintosh. PowerPC system softwar <Ä ° d ONLN dâpcyo )öe / ü ° d ONLN dçpoy´ ) Apple Computer ]Ä ° d ONLN dõp´yª )<, Inc. ° d ONLN d£y ÌÇ Û (Ä Ìp. O ° d ONLN d¶y ¸Ç )cm. ° d ONLN d™Ç ·ã (â ·Includes index. ° d ONLN d∫ã ·î% * ISBN 0-201-40727-2 ° d ONLN dÕî ·ù9 * 1. Macintosh (Computer) J ° d ONLN dÂîBùÄ )a2. PowerPC (Micr »Ä ° d ONLN dıîÄùå )>opr ˙ ° d ONLN d¯îåù® ) ocessor) ≥ ° d ONLN dî±ù’ )%
3. Systems ° d ONLN d ù ’¶ Ô (§ ’softwar 8Ä ° d ONLN dù ¶ ı )e.
Ä ° d ONLN dù ˛¶ )I. T 6 ° d ONLN dù ¶q ) itle: PowerPC system softwar !Ä ° d ONLN d6ùq¶v )he. ° d ONLN d9¶ ’Ø (≠ ’
QA76.8.M3I528 F ° d ONLN dG¶Ø$ )?1994 ° d ONLN dLØ ’∏
(∂ ’005.4'469—dc20 ÷ ° d ONLN d[Ø‘∏Ú )ˇ93-50182 M ° d ONLN dd∏‚¡Ô + CIP ˇÙ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ ∫˙ , Palatino
. Ñ` (‡ iii 4 ^ H¿
^ H ö 4 ^ H ö
° d ONLN d ^ ∫ w ( p ∫Contents
ˇ·ˇ‚7^
° d ONLN d ò ∫ § “ *1Figur R¿ ° d ONLN d ò “ § Ê )es, T è ° d ONLN d ò Â §6 )ables, and Listings |@ ° d ONLN d ( òK §V )fvii
¬ H … 4 √ H … ƒ H ƒ
ˇ·ˇ‚7^ , Helvetica
° d ONLN d , ∂ H ¡ m ( æ HPreface
° d ONLN d 4 ≥ ∫ ¬ ‚ )rAbout ∑@ ° d ONLN d : ≥ ‚ ¬ )( This Book
Û@ ° d ONLN d E µ4 ¡< )Rix ° d ONLN d I … ∫ ’" ( “ ∫Related Documentation T‡ ° d ONLN d ` …7 ’? )}xi ° d ONLN d c ÷ ∫ ‚ ı ( fl ∫
Format of a T ¿ ° d ONLN d p ÷ ı ‚6 );ypical Chapter M ° d ONLN d Ä ÷J ‚R )Uxi ° d ONLN d É „ ∫ ÔE ( Ï ∫ Conventions Used in This Book Ä ° d ONLN d ¢ „Z Ôd )†xii ° d ONLN d ¶ ƒ ¸ ˛ ( ˘ ƒ
Special Fonts °‡ ° d ONLN d µ ¸ )Nxii ° d ONLN d π ˝ ƒ ( ƒT ∫¿ ° d ONLN d ∫ ˝ … )
ypes of Notes )` ° d ONLN d … ˝ $ )Qxii ° d ONLN d Õ
ƒ& ( ƒBit Numbering and W ˇ` ° d ONLN d ‡
%. )aor 9‡ ° d ONLN d ‚
/I )
d Size «` ° d ONLN d Í
]g ).xii ° d ONLN d Ó ƒ#V ( ƒ Assembly-Language Information ?Ä ° d ONLN d
k#x )ßxiv ° d ONLN d$ ∫0 (- ∫Development Envir H‡ ° d ONLN d"$02 )Wonment A ° d ONLN d*$G0T )6xiv ° d ONLN d.1 ∫= fi (: ∫For Mor ß ° d ONLN d51 fi= )$
e Information " ° d ONLN dD1/=9 )Qxv
m Ht 4n Ht o Ho
ˇ·ˇ‚7^
° d ONLN dGa Hl x (i H Chapter 1
° d ONLN dQ^ ∫mø )r'Introduction to PowerPC System Software
‡ ° d ONLN dz`”l‡ (i”1-1 ° d ONLN dt ∫Äu (} ∫&Overview of the PowerPC System Softwar ö¿ ° d ONLN d•tuÄy )ªe d` ° d ONLN d®téÄõ )1-4 ° d ONLN d¨Å ∫ç (ä ∫The 68LC040 Emulator ¯@ ° d ONLN d¬Å3ç@ )y1-6 ° d ONLN dΔé ƒö (ó ƒEmulator Operation ï† ° d ONLN d⁄é1ö> )m1-7 ° d ONLN dfiõ ƒß" (§ ƒEmulator Limitations ;@ ° d ONLN dÙõ7ßD )s1-8 ° d ONLN d¯® Œ¥ ‰ (± ŒCopr ”† ° d ONLN d¸® ‰¥ )ocessors ¢ ° d ONLN d® ¥* )91-9 ° d ONLN d
µ Œ¡ ‚ (æ ŒInstr
‡ ° d ONLN dµ „¡ )uction T ° d ONLN dµ¡% )$imings M@ ° d ONLN d µ9¡F )21-9 ° d ONLN d#¬ ŒŒ (À Œ
Deleted Instr ÓÄ ° d ONLN d0¬Œ' )9uctions Ä ° d ONLN d9¬<ŒI )51-9 ° d ONLN d=œ Œ€ (ÿ ŒUnsupported Instr ˛¿ ° d ONLN dNœ €Z )R
uction Featur œ ° d ONLN d[œ[€d );es ’† ° d ONLN d_œx€ä ) 1-10 ° d ONLN dd‹ ŒË ‚ ( ŒInstr
‡ ° d ONLN di‹ „Ë )
uction Caches ÷ ° d ONLN dx‹4ËF )Q1-10 ° d ONLN d}È Œı  (Ú ŒAddr C¿ ° d ONLN dÅÈ Êı )ess Err ⁄¿ ° d ONLN dàÈı? )
or Exceptions Ò‡ ° d ONLN dóÈSıe )P1-10 ° d ONLN dúˆ Œ Ó (ˇ ŒBus Err 3@ ° d ONLN d£ˆ Ô+ )!
or Exceptions J` ° d ONLN d≤ˆ?L )P1-1 † ° d ONLN dµˆLQ )
1 ° d ONLN d∑ Œ] ( ŒMemory-Mapped I/O Locations 6† ° d ONLN d‘r )§1-1 ˝‡ ° d ONLN d◊~É ) 1 ° d ONLN dŸ ∫ Ú ( ∫
Mixed Mode ;¿ ° d ONLN d )M1-13 ° d ONLN dÍ ƒ) œ (& ƒCr \ ° d ONLN dÏ œ) ) oss-Mode Calls @ ° d ONLN d¸ ')9 )X1-14 ° d ONLN d* ƒ6 (3 ƒRoutine Descriptors È ° d ONLN d*06B )l1-15 ° d ONLN d7 ƒC/ (@ ƒMemory Considerations ° d ONLN d27DCV )Ä1-19 ° d ONLN d7D ∫P2 (M ∫The PowerPC Native Envir ô ° d ONLN dOD2PS )xonment ë@ ° d ONLN dWDhPz )61-19 ° d ONLN d\Q ƒ] Ú (Z ƒ Fragments @ ° d ONLN dgQ] )C1-20 ° d ONLN dl^ Œj Ì (g ŒThe Str Ä ° d ONLN ds^ Ój ) uctur ¢` ° d ONLN dx^jF )e of Fragments 4† ° d ONLN dà^[jm )V1-22 ° d ONLN dçk Œw) (t ŒImports and Exports ∑@ ° d ONLN d¢k=wO )o1-23 ° d ONLN dßx ŒÑ Á (Å ŒThe T ÒÄ ° d ONLN d¨x ÊÑ- )able of Contents Ø ° d ONLN dæxBÑT )\1-26 ° d ONLN d√Ö Œë (é ŒSpecial Routines y‡ ° d ONLN d’Ö+ë= )]1-29 ° d ONLN d⁄í Œû (õ ŒFragment Storage @ ° d ONLN dÏí1ûC )c1-30 ° d ONLN dÒü Œ´ (® ŒExecutable Resour ˜† ° d ONLN dü ´, )Qces nÄ ° d ONLN düA´S )"1-34 ˇX @ ˇ ˇˇˇˇ @
Routine Flags 4 ° d ONLN d∏%1 )Q2-34 ° d ONLN dΩ2 ∞> ƒ (; ∞Instr
‡ ° d ONLN d¬2 ≈> Û ) uction Set ‰@ ° d ONLN dÕ2 Ú> ˝ )-Ar pÄ ° d ONLN dœ2 ˛>$ ) chitectur %@ ° d ONLN dÿ2%>. )'es +‡ ° d ONLN d‹2B>T ) 2-35 . ° d ONLN d·? ¶K Œ (H ¶Data Str l ° d ONLN dÈ? ŒK ‰ )(uctur >` ° d ONLN dÓ? ‰K Ì )es >` ° d ONLN dÚ?K ) 2-36 . ° d ONLN d˜L ∞X Ó (U ∞
Routine Recor ¿ ° d ONLN dL ÔX ˘ )?ds kÄ ° d ONLN dL
X ) 2-36 ° d ONLN d
Y ∞e (b ∞Routine Descriptors È ° d ONLN d"Y e. )l2-37 ° d ONLN d'f ¶r2 (o ¶Mixed Mode Manager Routines ˚ ° d ONLN dDfFrX )†2-38 ° d ONLN dIs ∞ ª (| ∞Cr \ ° d ONLN dKs ª ) +eating and Disposing of Routine Descriptors ∞† ° d ONLN dxsì• )ÿ2-39 ° d ONLN d}Ä ∞å (â ∞Calling Routines vi l† ° d ONLN dêÄåD )Ua Universal Pr D ° d ONLN dûÄDåb )?ocedur €` ° d ONLN d§Äbåç )
e Pointers ôÄ ° d ONLN d∞Ä¢å¥ )@2-42 ° d ONLN dµç ∞ô ˇ (ñ ∞Determining Instr Í ° d ONLN dΔç ˇô- )O uction Set ¿` ° d ONLN d—ç-ô8 ).Ar L† ° d ONLN d”ç9ô_ ) chitectur ` ° d ONLN d‹ç`ôi )'es ° d ONLN d‡ç}ôè ) 2-44 ˇ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ ∫˙ , Palatino
. ‡ (‡v 4 ^ H¿ ° d ONLN d \ ∫ hf ( e ∫!Summary of the Mixed Mode Manager  ° d ONLN d # \z hå )¿2-45 ° d ONLN d ( i ƒ u ˘ ( r ƒ C Summary ᆠ° d ONLN d 3 i
u )I2-45 ° d ONLN d 8 v Œ Ç ˙ ( Œ Constants Æ ° d ONLN d C v Ç )@2-45 ° d ONLN d H É Œ è ’ ( å ŒD =@ ° d ONLN d I É ÷ è Î )ata T :` ° d ONLN d N É Î è ˚ )ype ï@ ° d ONLN d Q É ˚ è ˇ )s “@ ° d ONLN d T É è% )2-48 ° d ONLN d Y ê Œ úZ ( ô ŒMixed Mode Manager Routines ˚ ° d ONLN d v ên úÄ )†2-49
à H ” 4 Õ H ” Œ H Œ
ˇ·ˇ‚7^ , Helvetica
° d ONLN d { ¿ H À x ( » H Chapter 3
° d ONLN d Ö Ω ∫ ÃV )rCode Fragment Manager
⁄‡ ° d ONLN d ú øj Àw )∞3-1 ° d ONLN d ° ” ∫ flW ( ‹ ∫ About the Code Fragment Manager 1` ° d ONLN d ¬ ”l fly )≤3-3 ° d ONLN d Δ ‡ ƒ Ï Ú ( È ƒ Fragments @ ° d ONLN d — ‡ Ï )C3-4 ° d ONLN d ’ Ì ƒ ˘ ( ˆ ƒImport Library Sear -† ° d ONLN d Ë Ì ˘4 )Xching ∏ ° d ONLN d Ô ÌH ˘U ),3-5 ° d ONLN d Û ˙ ƒ À ( ƒV ú` ° d ONLN d Ù ˙ )ersion Checking ? ° d ONLN d ˙&3 )\3-7 ° d ONLN d ∫U ( ∫ Using the Code Fragment Manager p† ° d ONLN d*j| )∞3-10 ° d ONLN d/ ƒ 4 ( ƒLoading Code Fragments Á ° d ONLN dGH Z )Ñ3-10 ° d ONLN dL! ƒ- œ (* ƒCr \ ° d ONLN dN! œ-Z ) eating a Code Fragment Resour €@ ° d ONLN dk!Z-c )ãce ° d ONLN do!x-ä ) 3-12 ° d ONLN dt. ƒ: (7 ƒGetting Information ãÄ ° d ONLN dà. :é )[About Exported Symbols 5 ° d ONLN d†.£:µ )Ñ3-14 ° d ONLN d•; ∫GB (D ∫Code Fragment Manager Refer @ ° d ONLN d¿;CGV )âence ı ° d ONLN dΔ;jG| )'3-15 ° d ONLN dÀH ƒT Á (Q ƒData Str `` ° d ONLN d”H ËT ˇ )$uctur Ê@ ° d ONLN dÿH ˇT )es χ ° d ONLN d‹H T. ) 3-15 ° d ONLN d·U ŒaN (^ Œ Fragment Initialization Block @† ° d ONLN d Ucau )ï3-15 ° d ONLN db Œn= (k ŒFragment Location Recor ◊¿ ° d ONLN d b=nC )od ÛÄ ° d ONLN d bWni )3-16 ° d ONLN d$o Œ{8 (x ŒMemory Location Recor † ° d ONLN d9o9{? )kd ;` ° d ONLN d<oS{e )3-17 ° d ONLN dA| Œà' (Ö ŒDisk Location Recor á@ ° d ONLN dT|'à- )Yd £ ° d ONLN dW|AàS )3-17 ° d ONLN d\â Œï9 (í ŒSegment Location Recor _` ° d ONLN drâ9ï? )kd { ° d ONLN duâSïe )3-18 ° d ONLN dzñ ƒ¢\ (ü ƒ Code Fragment Manager Routines ÛÄ ° d ONLN döñp¢Ç )¨3-18 ° d ONLN dü£ ŒØ$ (¨ ŒLoading Fragments ı ° d ONLN d≤£8ØJ )j3-19 ° d ONLN d∑∞ Œº. (π ŒUnloading Fragments Z` ° d ONLN dÃ∞CºU )u3-23 ° d ONLN d—Ω Œ… (Δ ŒFinding Symbols r‡ ° d ONLN d‚Ω-…? )_3-24 ° d ONLN dÁ ƒ÷ (” ƒ Fragment-Defi )¿ ° d ONLN dÙ ÷? )A ned Routines ç‡ ° d ONLN d S÷e )N3-26 ° d ONLN d◊ ƒ„ „ (‡ ƒResour v@ ° d ONLN d
◊ „„ ) ces Ì ° d ONLN d◊„ )!3-28 ° d ONLN d‰ ŒG (Ì ŒThe Code Fragment Resour Ê ° d ONLN d/‰GP )yce ° d ONLN d3‰ew ) 3-28 ° d ONLN d8Ò ∫˝ ø (˙ ∫S ø¿ ° d ONLN d9Ò ø˝r )#ummary of the Code Fragment Manager ›Ä ° d ONLN d^ÒÜ˝ò )«3-32 ° d ONLN dc˛ ƒ
˘ ( ƒ C Summary ᆠ° d ONLN dn˛
)I3-32 ° d ONLN ds Œ ˙ ( Œ Constants Æ ° d ONLN d~ )@3-32 ° d ONLN dÉ Œ$ ’ (! ŒD =@ ° d ONLN dÑ ÷$ Î )ata T :` ° d ONLN dâ Î$ ˇ )ypes “@ ° d ONLN dè$% )(3-33 ° d ONLN dî% Œ1f (. Œ Code Fragment Manager Routines ÛÄ ° d ONLN d¥%z1å )¨3-34 ° d ONLN dπ2 Œ> (; Œ Fragment-Defi )¿ ° d ONLN dΔ2>I )A ned Routines ç‡ ° d ONLN d‘2]>o )N3-35 ° d ONLN dŸ? ƒK ˛ (H ƒ Result Codes ï` ° d ONLN dÁ?K$ )N3-35
{ HÇ 4| HÇ } H}
ˇ·ˇ‚7^
° d ONLN dÏo Hz x (w H Chapter 4
° d ONLN dˆl ∫{2 )rException Manager
° d ONLN d nGzT )ç4-1 ° d ONLN dÇ ∫é> (ã ∫About the Exception Manager o@ ° d ONLN d+ÇSé` )ô4-3 ° d ONLN d/è ƒõ (ò ƒException Contexts ‡ ° d ONLN dCè.õ; )j4-4 ° d ONLN dGú ƒ® (• ƒT ∫¿ ° d ONLN dHú …® )ypes of Exceptions K ° d ONLN d\ú0®= )g4-5 ˇ
¿ ° d ONLN d ≈ ™5 ∂B )E4-1 ’ ° d ONLN d » ™A ∂F ) 1 ° d ONLN d ∑ ¶ √ … ( ¿ ¶Data Str `` ° d ONLN d “ ∑ √ · )$uctur Ê@ ° d ONLN d ◊ ∑ · √ Í )es χ ° d ONLN d € ∑ ˛ √ ) 4-12 ° d ONLN d ‡ ƒ ∞ –) ( Õ ∞Machine Information Recor ° d ONLN d ˘ ƒ* –4 )zds f‡ ° d ONLN d ˝ ƒH –Z ) 4-12 ° d ONLN d — ∞ ›' ( ⁄ ∞Register Information Recor ˛† ° d ONLN d —' ›1 )wds W` ° d ONLN d —F ›X ) 4-12 ° d ONLN d% fi ∞ ÍB ( Á ∞ Floating-Point Information Recor @ ° d ONLN dE fiC ÍM )ìds t ° d ONLN dI fia Ís ) 4-14 ° d ONLN dN Î ∞ ˜ π ( Ù ∞M ı@ ° d ONLN dO Î π ˜ ) emory Exception Recor ûÄ ° d ONLN dd Î ˜* )gds ˜@ ° d ONLN dh Î> ˜P ) 4-15 ° d ONLN dm ¯ ∞/ ( ∞Exception Information Recor ≈‡ ° d ONLN dà ¯/9 )ds † ° d ONLN då ¯N` ) 4-16 ° d ONLN dë ¶% ( ¶Exception Manager Routines 1` ° d ONLN d≠:L )î4-17 ° d ONLN d≤ ¶ ( ¶Application-Defi † ° d ONLN d¬ * )J ned Routines I¿ ° d ONLN d–? Q )O4-17 ° d ONLN d’ ú+; (( ú Summary of the Exception Manager ` ° d ONLN d˜ P+b )¥4-19 ° d ONLN d¸, ¶8 € (5 ¶ C Summary ᆠ° d ONLN d, Ô8 )I4-19 ° d ONLN d 9 ∞E ‹ (B ∞ Constants Æ ° d ONLN d9 E )@4-19 ° d ONLN d F ∞R Õ (O ∞Data T :` ° d ONLN d"F ÕR · ) ypes “@ ° d ONLN d(F ıR )(4-19 ° d ONLN d-S ∞_/ (\ ∞Exception Manager Routines 1` ° d ONLN dISD_V )î4-22 ° d ONLN dN` ∞l ˙ (i ∞Application-Defi † ° d ONLN d^` ˙l4 )J ned Routines I¿ ° d ONLN dl`Il[ )O4-22
ú *£¯ 4ù *£¯ û *û¯
ˇ·ˇ‚7^ , Helvetica
° d ONLN dqç úú ” (ò úGlossary
∏Ä ° d ONLN d{è Áõ ˝ )KGL-1
“ *Ÿ¯ 4” *Ÿ¯ ‘ *‘¯
ˇ·ˇ‚7^
° d ONLN dÅ√ ú“ æ (Œ úIndex
º‡ ° d ONLN dà≈ “— Ê )6IN-1 ˇR @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ ∫˙ , Palatino
. I (‡
vii 4 ^ H¿
ˇˇ—Ú ˇ◊ ° d ONLN d [ ∫ o ‰ ( j ∫Figur {z ° d ONLN d [ ‰ o )*es, T 5 ° d ONLN d
° d ONLN d 7 ù ®# )Cix ° d ONLN d ; ± ∫ º Â ( π ∫
Figure P-1 ° d ONLN d F ± ºY )N680x0 bit numbering P ° d ONLN d [ ±l ºv )dxiii ° d ONLN d ` Ω ∫ » Â ( ≈ ∫
Figure P-2 ° d ONLN d k Ω »A )N
PowerPC bit n ¿ ° d ONLN d x ΩB »g ):umbering ÇÄ ° d ONLN d Ç Ωy »É )7xiii ° d ONLN d á ’ ∫ ‡ ‚ ( › ∫ Table P-1 ° d ONLN d ë ’ ‡s )NSizes of memory operands Ép ° d ONLN d ´ ’Ö ‡è )}xiii
H
4 H
∫
ˇ·ˇ‚7^
° d ONLN d ∞ ¯ H s ( H Chapter 1
° d ONLN d ∫ ˘ ∫á )r'Introduction to PowerPC System Software
Ï@ ° d ONLN d „ ˘ô¶ )fl1-1 ° d ONLN d Ë
∫ ‰ ( ∫
Figure 1-1 ° d ONLN d Û
)N:The system software for PowerPC processor-based Macintosh ° d ONLN d-"2 *
computers Ä¿ ° d ONLN d8D"Q )<1-5 ° d ONLN d<" ∫- ‰ (* ∫
Figure 1-2 ° d ONLN dG"-Å )N Creating imports in a fragment Åp ° d ONLN dg"ì-• )ã1-24 ° d ONLN dl. ∫9 ‰ (6 ∫
Figure 1-3 ° d ONLN dw.9 )NA 0 ° d ONLN dx.9P ) transition vector ∞ ° d ONLN då.b9t )T1-27 ° d ONLN dë9 ∫D ‰ (A ∫
Figure 1-4 ° d ONLN dú9D§ )N&The structure of a PowerPC application – ° d ONLN dƒ9∑D… )Ø1-31 ° d ONLN d…E ∫P ‰ (M ∫
)Û1-54 ° d ONLN dÿ∏ ∫√ Í (¿ ∫ Figure 1-15 ° d ONLN d‰∏√ÿ )N2Organization of memory when virtual memory is not ° d ONLN d¬Õ( *
enabled Ñ0 ° d ONLN d ¬:ÕL )21-56 ° d ONLN d$Õ ∫ÿ Í (’ ∫ Figure 1-16 ° d ONLN d0Õÿ« )N0The structure of a PowerPC application partition á¿ ° d ONLN dbÕŸÿÎ )—1-60 ° d ONLN dgŸ ∫‰ Í (· ∫ Figure 1-17 ° d ONLN dsŸ‰Ó )N5The Memory control panel for PowerPC processor-based ° d ONLN d®„Ó] *
Macintosh computers @ ° d ONLN dΩ„pÓÇ )h1-69 ° d ONLN d¬˚ ∫ Ê ( ∫ Listing 1-1 ° d ONLN dŒ˚y )N Creating a routine descriptor P ° d ONLN dÌ˚åû )Ñ1-17 ° d ONLN dÚ ∫ Ê ( ∫ Listing 1-2 . ° d ONLN d˛( )NThe defi ° d ONLN d(Y ) nition of the ,
Courier ° d ONLN dYΩ )1NewControlActionProc ° d ONLN d(Ω€ )d routine ° d ONLN d2Ìˇ )01-18 . ° d ONLN d7 ∫ Ê ( ∫ Listing 1-3 ° d ONLN dC Ò )N<Creating a routine descriptor for a control action procedure â ° d ONLN dÅ )˚1-19 ° d ONLN dÜ ∫( Ê (% ∫ Listing 1-4 ° d ONLN dí (
)NT ° d ONLN dì
(ë )"esting for unresolved soft imports Ñ` ° d ONLN d∑ £(µ )ñ1-25 ° d ONLN dº) ∫4 Ê (1 ∫ Listing 1-5 . ° d ONLN d»)4t )NThe Rez input for a sample ° d ONLN d„)t4í )l'cfrg' ° d ONLN dÈ)í4∏ ) resource ° d ONLN dÙ) 4‹ )81-32 . ° d ONLN d˘4 ∫? Ê (< ∫ Listing 1-6 ° d ONLN d4?a )NRez input for a list defi Ép ° d ONLN d 4a?µ )Ynition procedure stub à‡ ° d ONLN d54«?Ÿ )f1-35 ° d ONLN d:@ ∫K Ê (H ∫ Listing 1-7 ° d ONLN dF@KÇ )N Using an accelerated resource Ö‡ ° d ONLN de@îK¶ )å1-37 ° d ONLN djK ∫V Ê (S ∫ Listing 1-8 ° d ONLN dvKV‰ )N6Some acceptable global declarations in an accelerated ° d ONLN d¨U`+ *
resource Ć ° d ONLN d∂U=`O )51-39 ° d ONLN dªa ∫l Ê (i ∫ Listing 1-9 ° d ONLN d«al )N5Some unacceptable global declarations and code in an ° d ONLN d¸kv\ *
accelerated resource É¿ ° d ONLN dknvÄ )f1-39 ° d ONLN dv ∫Å Î (~ ∫ Listing 1-10 ° d ONLN d$vÅi )NUsing a private resource † ° d ONLN d>v|Åé )t1-40 ° d ONLN dCÇ ∫ç Î (ä ∫ Listing 1-11 ° d ONLN dPÇçj )NDeclaring an application’ Z ° d ONLN diÇjçfi )b s QuickDraw global variables \ ° d ONLN dáÇç )Ü1-59 ° d ONLN dåç ∫ò Î (ï ∫ Listing 1-12 ° d ONLN dôçò )NA 0 ° d ONLN döçò\ ) sample 680x0 VBL ≥† ° d ONLN d´ç[ò )M task defi ∂p ° d ONLN dµçòî )$nition 7† ° d ONLN dΩçßòπ )(1-61 ° d ONLN d¬ô ∫§ Î (° ∫ Listing 1-13 ° d ONLN dœô§ )NA 0 ° d ONLN d–ô§_ ) conditionalized VBL 3∞ ° d ONLN d‰ô_§É )Q task defi 6Ä ° d ONLN dÓôɧò )$nition ∑∞ ° d ONLN dˆô™§º )'1-62 ° d ONLN d˚§ ∫Ø Î (¨ ∫ Listing 1-14 ° d ONLN d§Øî )N!Patching an Operating System trap à∞ ° d ONLN d+§¶Ø∏ )û1-67 ° d ONLN d0∞ ∫ª Î (∏ ∫ Listing 1-15 . ° d ONLN d=∞ª )NW + ° d ONLN d>∞ªB )aiting to call + ° d ONLN dM∞BªQ )2the + ° d ONLN dQ∞Qªí )
WaitNextEvent + ° d ONLN d^∞íªµ )A function + ° d ONLN di∞«ªŸ )51-72 ˇå @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ *ˇ¯ , Palatino
. (· *viii 4 ^ *¿¯
h * n¯ 4 i * n¯ j ú j¯
ˇ·ˇ‚7^ , Helvetica ° d ONLN d \ * h U ( e * Chapter 2
° d ONLN d
] ú h )rMixed Mode Manager
‚† ° d ONLN d ] h% )|2-1 ° d ONLN d # q ú | Δ ( y ú
Figure 2-5 ° d ONLN d ° Í ¨ )NA 0 ° d ONLN d ° ¨s ) PowerPC-to-680x0 switch frame É@ ° d ONLN d# °Ö ¨ó )ï2-13 ° d ONLN d( ≠ ú ∏ Δ ( µ ú
Figure 2-6 ° d ONLN d3 ≠ Í ∏G )NProcedure information f ‡ ° d ONLN dJ ≠H ∏£ )^or a stack-based routin á ° d ONLN da ≠£ ∏® )[e á– ° d ONLN dd ≠∫ ∏à )2-17 ° d ONLN di π ú ƒ Δ ( ¡ ú
Figure 2-7 ° d ONLN dt π Í ƒ± )N2Procedure information for a register-based routine Ü ° d ONLN d® π√ ƒ’ )Ÿ2-19 ° d ONLN d≠ ≈ ú – Δ ( Õ ú
Figure 2-8 ° d ONLN d∏ ≈ Í –A )NGeneral structure of a Éê ° d ONLN dŒ ≈A –F )Wn Ñ` ° d ONLN dœ ≈F –H ) Ä ° d ONLN d– ≈I –ç )executable code Ä ° d ONLN d‡ ≈ç –™ )Dresourc P ° d ONLN dÁ ≈´ –∞ ) e ° d ONLN dÍ ≈¬ –‘ )2-25 ° d ONLN dÔ — ú ‹ Δ ( Ÿ ú
Figure 2-9 ° d ONLN d˙ — Í ‹s )N#General structure of a fat resource ÖÄ ° d ONLN d —Ö ‹ó )õ2-26 ° d ONLN d$ È ú Ù √ ( Ò ú Table 2-1 ° d ONLN d. È Í Ùd )N Limits on the number of specifi Ñ¿ ° d ONLN dM Èd Ù„ )z able parameters in a procedure ° d ONLN dl Û Í ˛ ( ˚ Í information P ° d ONLN dy Û) ˛; )?2-20 ° d ONLN d~ ú » ( ú Listing 2-1 ° d ONLN dä Í )N$Sample glue code for a 680x0 routine 0 ° d ONLN d∞ í§ )®2-12 ° d ONLN dµ ú" » ( ú Listing 2-2 ° d ONLN d¡ Í"s )N#Creating global routine descriptors Ñ` ° d ONLN dÊÖ"ó )õ2-21 ° d ONLN dÎ# ú. » (+ ú Listing 2-3 ° d ONLN d˜# Í. )N
Creating l ° d ONLN d#.n )'ocal routine descriptors ¿ ° d ONLN d#Ä.í )o2-22 ° d ONLN d / ú: » (7 ú Listing 2-4 ° d ONLN d,/ Í:p )N#Creating static routine descriptors LJ ° d ONLN dQ/Ç:î )ò2-23 ° d ONLN dV; úF » (C ú Listing 2-5 ° d ONLN db; ÍFq )N$Building a static routine descriptor Ö ° d ONLN dà;ÉFï )ô2-23
j *p¯ 4k *p¯ l úl¯
ˇ·ˇ‚7^
° d ONLN dç^ *j U (g * Chapter 3
° d ONLN dó_ új )rCode Fragment Manager
e` ° d ONLN dÆ_)j6 )ç3-1 ° d ONLN d≥s ú~ Δ ({ ú
Figure 3-1 . ° d ONLN dæs Í~à )N'Structure of a compiled code fragment ( ,
Courier ° d ONLN dÂsà~¶ )û'cfrg' ° d ONLN dÎs¶~œ )
) resource ° d ONLN d˜s·~Û );3-29 . ° d ONLN d¸ úä Δ (á ú
Figure 3-2 ° d ONLN d ÍäÆ )N0The format of a code fragment information record ÜP ° d ONLN d9¿ä“ )÷3-30 ° d ONLN d>ó ú¢ » (ü ú Listing 3-1 ° d ONLN dJó Í¢• )N-Pseudocode for the version-checking algorithm ` ° d ONLN dyó∏¢≈ )Œ3-9 ° d ONLN d}£ úÆ » (´ ú Listing 3-2 ° d ONLN d⣠ÍÆx )N!Loading a resource-based fragment – ° d ONLN d¨£ãÆò )°3-1 ^∞ ° d ONLN dØ£óÆú ) 1 ° d ONLN d±Ø ú∫ » (∑ ú Listing 3-3 ° d ONLN dΩØ Í∫e )N Loading a disk-based fragment P ° d ONLN d‹Øx∫Ö )é3-1 ^0 ° d ONLN dflØÑ∫â ) 1 ° d ONLN d·ª úΔ » (√ ú Listing 3-4 . ° d ONLN d̪ ÍΔÇ )N(The Rez input for a typical application’ V ° d ONLN dªÇΔâ )òs V ° d ONLN dªâΔß )'cfrg' V ° d ONLN d ªßΔÕ ) resource V ° d ONLN d(ªflΔÒ )83-12 . ° d ONLN d-« ú“ » (œ ú Listing 3-5 . ° d ONLN d9« Í“ä )N+The Rez input for a typical import library’ V ° d ONLN dd«ä“ë )†s V ° d ONLN df«ë“Ø )'cfrg' V ° d ONLN dl«Ø“± ) . ° d ONLN dm— Í‹
(Ÿ Íresource Ć ° d ONLN dw— ‹1 )53-13 ° d ONLN d|› úË » ( ú Listing 3-6 ° d ONLN dà› ÍËD )NFinding symbol names Ç@ ° d ONLN dû›VËh )l3-14
*¯ 4
*¯ ú¯
ˇ·ˇ‚7^
° d ONLN d£ * U ( * Chapter 4
° d ONLN d≠ ú ˙ )rException Manager
G@ ° d ONLN d¿
)q4-1 ° d ONLN d≈ ú » ( ú Listing 4-1 ° d ONLN d— Í ` )N Installing an exception handle
P ° d ONLN dÔa c )wr ° d ONLN dÚv É )4-6 ° d ONLN dˆ! ú, » () ú Listing 4-2 ° d ONLN d! Í, )NA 0 ° d ONLN d! ,T ) native exception handler
Macintosh on —Ä ° d ONLN d › ∂µ ¬◊ )>PowerP mÄ ° d ONLN d „ ∂ÿ ¬Ê )#C c t¿ ° d ONLN d Ê ∂Ê ¬ )
omputers. ° d ONLN d √ ∫ œi ( à ∫'It contains information you need to kno ÊÄ ° d ONLN d √i œw )Øw t ˇ‡ ° d ONLN d √w œ˛ ) o write applications and other ° d ONLN d9 – ∫ ‹ € ( Ÿ ∫softwar ‰¿ ° d ONLN d@ – € ‹ )! e that can r §¿ ° d ONLN dL – ‹^ )1un on PowerPC pr æ@ ° d ONLN d\ –^ ‹~ )Rocessor " ° d ONLN dc – ‹ )!-based Macintosh computers. ° d ONLN d ‚ ∫ Ó ” ( Î ∫The fi »Ä ° d ONLN dÖ ‚ ” Ó ‰ )rst r Ä ° d ONLN dä ‚  Ó` ) elease of the system softwar ˆ` ° d ONLN d¶ ‚` Óµ ){e for Macintosh on (` ° d ONLN dπ ‚∂ Óÿ )VPowerP ƒ` ° d ONLN dø ‚ÿ Ó )" C computers ° d ONLN dÀ Ô ∫ ˚ √ ( ¯ ∫pr G ° d ONLN dÕ Ô ƒ ˚L )
ovides a mixed or hybrid envir ̆ ° d ONLN dÎ ÔL ˚Δ )àonment: the system softwar ° d ONLN d Ô« ˚ÿ ){e pr !‡ ° d ONLN d Ôÿ ˚ ) ovides the ° d ONLN d ¸ ∫æ ( ∫>ability to execute both applications that use the native instr ” ° d ONLN dR ¸æ (æuction set of the ° d ONLN dd ∫ ˙ ( ∫ PowerPC micr §† ° d ONLN dp ˙ )@opr ·@ ° d ONLN ds › )1ocessor and applications that use the 680x0 instr U` ° d ONLN d§ fi
)’ uction set. ° d ONLN d∞ ∫"* ( ∫It accomplishes this by pr I¿ ° d ONLN d +"u )qoviding a very ef ° d ONLN d€v"| )Kfi ¿ ° d ONLN d›|"¸ ) cient 68LC040 Emulator that ° d ONLN d˘# ∫/ (, ∫emulates 680x0 instr ñÄ ° d ONLN d
#/ç )Zuctions with PowerPC instr Z` ° d ONLN d'#é/≥ )z uctions. " ° d ONLN d0#≥/à )%As a r Î@ ° d ONLN d6#Ã/ )esult, virtually ° d ONLN dG0 ∫<› (9 ∫Aall existing 680x0-based Macintosh applications and other softwar ä‡ ° d ONLN dà0›<
(9›
e modules ° d ONLN dí= ∫I (F ∫that conform to the pr y† ° d ONLN d®=I )a2ogramming interfaces and techniques documented in ° d ONLN d⁄J ∫V (S ∫the ›` ° d ONLN dfiJ V )Inside Macintosh ø` ° d ONLN dÓJVÃ )F* suite of books will execute without modifi ;‡ ° d ONLN dJÕV¯ )Ω
, Inc., pr êÄ ° d ONLN d#É›è¸ )$ovides ° d ONLN d*ê ∫ú ” (ô ∫MPW r@ ° d ONLN d-ê ”úˆ )A-based C and C++ compilers and other tools that you can use to cr ”` ° d ONLN dnêˆú
° d ONLN d∑ ∫√g (¿ ∫)should be able, with moderately little ef AŒ ° d ONLN d,∑h√ã )Æ
fort, to r •( ° d ONLN d6∑ã√‘ )#ework your sour ¢" ° d ONLN dE∑‘√ )Ice code so that ° d ONLN dUƒ ∫–c (Õ ∫'it can be compiled and built using the J† ° d ONLN d|ƒc–
° d ONLN dI ∫ Œ *Ther ¿ ° d ONLN dM œ Ó )e will a ⁄Ä ° d ONLN dU Ó ) lso be thir á¿ ° d ONLN d` º ),"d-party compilers and development ° d ONLN dÉ ∫) — (& ∫envir n† ° d ONLN dà —)û )+onments capable of generating PowerPC code. ,
Zapf Dingbats
° d ONLN d¥ §(™ )”u
° d ONLN d∂. ∫: (7 ∫Although the native r »Ä ° d ONLN dÀ.:Ç )_un-time execution envir P¿ ° d ONLN d‚.É:… )jonment of the fi |Ä ° d ONLN dÚ.…: )Frst version of the ° d ONLN d; ∫G ¸ (D ∫system softwar M‡ ° d ONLN d; ˝GI )Ce for PowerPC pr Õ† ° d ONLN d#;IGi )Locessor 1Ä ° d ONLN d*;jGı )! -based Macintosh computers is ° d ONLN dHH ∫T ’ (Q ∫signifi ˚ ° d ONLN dOH ’T ˛ )
cantly dif †‡ ° d ONLN dYH ˇT )*fer É` ° d ONLN d\H T" ) ent fr ˘† ° d ONLN dbH"Tá )om the execution envir 4 ° d ONLN dxHàT )fonment of curr $† ° d ONLN dÜH T )Bent 680x0-based ° d ONLN dñU ∫a— (^ ∫<Macintosh computers, you won’t need to worry about those dif ` ° d ONLN d“U“afi (^“fer Û‡ ° d ONLN d’U›a˜ ) ences ° d ONLN d€b ∫n0 (k ∫unless your existing code r µ‡ ° d ONLN dˆb0np )velies on specifi ‡ ° d ONLN d bqnˆ )A c information about the 680x0 ° d ONLN d $o ∫{ ˛ (x ∫execution envir ìÄ ° d ONLN d 3o ˛{ñ )D"onment. For example, if for some r
¿ ° d ONLN d Uoó{” )ô
eason you dir - ° d ONLN d bo”{ )<
ectly access ° d ONLN d o| ∫àO (Ö ∫"information in your application’s P@ ° d ONLN d ë|Oà¡ )ïA5 world, you’ll need to r {¿ ° d ONLN d ´|¡à˘ )r
ewrite those ° d ONLN d πâ ∫ïfi (í ∫@parts of code when porting your application to the PowerPC envir -† ° d ONLN d ˘âflï (íflonment. ° d ONLN d
ñ ∫¢ ‚ (ü ∫ Similarly õ@ ° d ONLN d
ñ ·¢) )', you’ll need to r º@ ° d ONLN d
ñ)¢Û )H-ewrite any parts of your code that depend on ° d ONLN d
° d ONLN d \ ú hv ( e ú2often depend on the fact that a pointer to the VBL ` ° d ONLN d 2 \w hí )€ task r Ô‡ ° d ONLN d 9 \ë h£ )ecor d@ ° d ONLN d = \§ h‚ )d is passed in ° d ONLN d L i ú u ü ( r úr E ° d ONLN d M i † u ø )egister „` ° d ONLN d U i ø u Œ ) A0. ° d ONLN d Y { ú á µ ( Ñ úThe fi »Ä ° d ONLN d _ { µ á )rst chapter in this book, qÄ ° d ONLN d y { á5 )k“Intr ®¿ ° d ONLN d ~ {5 ဠ)"oduction to PowerPC System Softwar ·@ ° d ONLN d † {€ áÁ )¶e,” *‡ ° d ONLN d £ {Ë áÍ )
° d ONLN d § à ú î • ( ë úpr G ° d ONLN d ¶ à ¶ î{ )
/ovides a general overview of the system softwar 8@ ° d ONLN d ’ à{ îö )’e that r 6† ° d ONLN d › àö îÊ ) uns on PowerPC ° d ONLN d Ï ï ú ° • ( û úpr G ° d ONLN d Ó ï ¶ ° Δ )
ocessor ´ ° d ONLN d ı ï Δ °Ë ) B-based Macintosh computers. It also describes in detail the mixed ° d ONLN d7 ¢ ú Æ ≥ ( ´ úenvir n† ° d ONLN d< ¢ ≥ Æ · ) onment pr Æ ° d ONLN dE ¢ · Æ‘ ).2ovided by the 68LC040 Emulator and the Mixed Mode ° d ONLN dw Ø ú ª √ ( ∏ úManager T† ° d ONLN d~ Ø √ ª )', as well as the new r Ó ° d ONLN dî Ø ªZ )[
un-time envir Q` ° d ONLN d° Ø[ ª )= onment used for native PowerPC ° d ONLN d¿ º ú » ÷ ( ≈ úapplications. F@ ° d ONLN dŒ º ◊ » › );Y ¿ ° d ONLN dœ º › » ) ou should r ◊Ä ° d ONLN d⁄ º »› )2/ead this chapter for general information about ° d ONLN d … ú ’ Ù ( “ úporting your existin ᆠ° d ONLN d … Ù ’ )X g softwar ˚Ä ° d ONLN d& … ’' ))e t áÄ ° d ONLN d) …( ’É ) o the PowerPC envir ¸ ° d ONLN d< …É ’Ì )[onment. Even if you do ° d ONLN dS ÷ ú ‚= ( fl ú%not intend to port your existing 680x ÍÄ ° d ONLN dx ÷= ‚f )° 0 softwar œ@ ° d ONLN dÅ ÷f ‚m ))e, ‡ ° d ONLN dÉ ÷n ‚€ ) you might still want to r § ° d ONLN dù ÷€ ‚Ì )mead ° d ONLN d° „ ú Ô8 ( Ï ú$this chapter for information about r ° d ONLN d≈ „9 Ô€ )ù!unning under the 68LC040 Emulator ó‡ ° d ONLN dÊ „⁄ Ô‹ )°. ° d ONLN dË ı ú ≥ ( ˛ úThe r Ä¿ ° d ONLN dÌ ı ≥G )!emaining chapters in this book pr ‹ ° d ONLN d ıGf )îovide r
† ° d ONLN d ıgw ) efer ∂¿ ° d ONLN d ıw· )ence material for the thr ° ° d ONLN d2 ı·Ì )jee ° d ONLN d5 ú Ù ( únew system softwar ø‡ ° d ONLN dG Ù8 )Xe managers intr x` ° d ONLN dV9~ )Eoduced in the fi ä@ ° d ONLN df~Ï )Erst version of the system ° d ONLN dÄ ú Ω ( úsoftwar ‰¿ ° d ONLN dá Ω )!e for PowerPC pr dÄ ° d ONLN dó
* )Mocessor »` ° d ONLN dû*Æ ) -based Macintosh computers. ¸¿ ° d ONLN d∫Æ¥ )ÑY Ω@ ° d ONLN dª¥„ )
ou should ° d ONLN d≈ ú( ü (% úr E ° d ONLN dΔ †( ) ead these chapters for specifi ∑‡ ° d ONLN d‰ (≈ )&c information on using the services pr Z† ° d ONLN d
Δ(ı )ß
ovided by ° d ONLN d) ú5Q (2 ú&those managers. The new system softwar 9@ ° d ONLN d:)R5è )∂
e managers ar ı† ° d ONLN dG)è5ì )=e ,
Zapf Dingbats
° d ONLN dI? úF ° (E ún
° d ONLN dK< ®H ) the Mixed Mode Manager Ì¿ ° d ONLN da<H¨ )r , which manages the mixed envir † ° d ONLN dÄ<≠H‹ )ì
onment of ° d ONLN däH ®T fi (Q ®
PowerPC pr z ° d ONLN dîH fiT ˛ )6ocessor fi ° d ONLN dõH ˛TÉ ) -based Macintosh computers r û† ° d ONLN d∑HÑTÛ )Üunning 680x0-based code
° d ONLN dœ] úd ° (c ún
° d ONLN d—Z ®f' ) the Code Fragment Manager Ê ° d ONLN dÍZ&f )~., which loads fragments (blocks of executable ° d ONLN df ®r∏ (o ®:PowerPC code and their associated data) into memory and pr ‘@ ° d ONLN dRf∏rÀ (o∏epar e ° d ONLN dVfÃr )es them ° d ONLN d^r ®~ · ({ ®
for execution
° d ONLN dlá úé ° (ç ún
° d ONLN dnÑ ®ê ) the Exception Manager $ ° d ONLN dÉÑêÁ )f1, which handles exceptions that occur during the ° d ONLN d¥ê ®úå (ô ®2execution of PowerPC applications or other softwar ßÄ ° d ONLN dÊêåúê )‰e
° d ONLN dË™ ú≤ ª (∞ úIMPORT Ä ° d ONLN dÓ™ ª≤ À ) ANT
ˇ·ˇ‚7^
° d ONLN dÚµ ú¡ (æ úSome of the system softwar «Ä ° d ONLN d µ¡Q )ye services intr Q ° d ONLN dµR¡ó )=oduced in the fi b‡ ° d ONLN d+µó¡” )Erst version of ° d ONLN d:¡ úÕ Ô ( úthe system softwar ´@ ° d ONLN dL¡ ÔÕ; )Se for PowerPC pr + ° d ONLN d\¡<Õ\ )Mocessor é‡ ° d ONLN dc¡\Õ› ) -based Macintosh computers ° d ONLN d~Õ úŸ Î (÷ úmight in the futur _‡ ° d ONLN dêÕ ÎŸ∂ )O-e be available on Macintosh computers that ar qÄ ° d ONLN dΩÕ∂ŸŒ )Àe not ° d ONLN d√Ÿ ú (‚ úbased on the PowerPC micr Ú‡ ° d ONLN d‹ŸÂ% )zopr /Ä ° d ONLN dflŸ&ÂF )ocessor † ° d ONLN dÊŸF— ) ". For example, it’s possible that ° d ONLN d úÒY (Ó ú(the Code Fragment Manager (and the entir Æ ° d ONLN d0ÂYÒd )Ωe r Ù‡ ° d ONLN d3ÂdÒ† )
un-time envir X@ ° d ONLN d@°Ò≈ )=onment ° d ONLN dGÒ ú˝d (˙ ú-based on fragments) will be included in futur ® ° d ONLN dtÒd˝œ )»e versions of the system ° d ONLN dç˝ ú Ω ( úsoftwar ‰¿ ° d ONLN dî˝ Ω q )!'e for 680x0-based Macintosh computers. ñ† ° d ONLN dª˝q ä )¥As a r _‡ ° d ONLN d¡˝ã ⁄ )esult, some of the ° d ONLN d‘ úv ( ú0information in this book might eventually be mor #@ ° d ONLN d w⁄ )€e generally applicable ° d ONLN d ú!M ( ú*than the title of this book might suggest.
pÄ ° d ONLN dFS Z )∑s
ˇˇÓ ° d ONLN dH& ú2 ¡ (/ ú If you ar flR ° d ONLN dQ& ¡2 Ú )% e new to pr d= ° d ONLN d\& Û2’ )2/ogramming for Macintosh computers, you should r ‡Û ° d ONLN dã&’2˜ )‚ead the ° d ONLN dì3 ú? ¥ (< úbook ¿ ° d ONLN dò3 µ?' )Inside Macintosh: Overview U@ ° d ONLN d≤3'?U )r for an intr #¿ ° d ONLN dæ3V?◊ )/ oduction to general concepts ° d ONLN d‹@ úL ‚ (I úof Macintosh pr v ° d ONLN dÎ@ ‚L )F ogramming. 0Ä ° d ONLN dˆ@L! )9Y Ò ° d ONLN d˜@ Lg )ou should also r ‹† ° d ONLN d @gLÀ )Gead other books in the ]` ° d ONLN d @ÃLÊ )eInside ° d ONLN d %M úY Δ (V ú Macintosh pÄ ° d ONLN d .M «Y )+ series for specifi ‡ ° d ONLN d AMYÛ )J3c information about other aspects of the Macintosh ° d ONLN d tZ úf ¢ (c úT µ¿ ° d ONLN d uZ °f° )8oolbox and the Macintosh Operating System. In particular ‘† ° d ONLN d ≠Z°fà (c°
, to benefi Ä ° d ONLN d ∏ZÕfÎ ),t most ° d ONLN d øg ús £ (p úfr ò‡ ° d ONLN d ¡g £s! ) om this book, you should alr eÄ ° d ONLN d ›g"só )eady be familiar with the r é ° d ONLN d ¯gós” )u
un-time envir Ò` ° d ONLN d
g”s˜ )<onment ° d ONLN d
t úÄÇ (} ú5of 680x0 applications, as described in the two books b@ ° d ONLN d
° d ONLN d ô ∫ •% ( ¢ ∫This book is part of a lar lÄ ° d ONLN d 1 ô% • )k6ger suite of books that contain information essential ° d ONLN d g ¶ ∫ ≤± ( Ø ∫5for developing PowerPC applications and other softwar x` ° d ONLN d ú ¶± ≤µ )˜e B ° d ONLN d ù ¶∂ ≤∏ ). ,
Zapf Dingbats
° d ONLN d ü º ∫ √ ø ( ¬ ∫n
° d ONLN d ° π Δ ≈ À ) F ° d ONLN d ¢ π à ≈ )Hor information about the PPCC compiler that you can use to compile your ° d ONLN d Í ≈ Δ — Ÿ ( Œ Δsour ˛† ° d ONLN d Ó ≈ Ÿ —± )0ce code into a PowerPC application, see the book Ä ° d ONLN d ≈≤ —¯ )Ÿ C/C++ Compiler ≤@ ° d ONLN d- ≈¯ —˙ )F 2@ ° d ONLN d. ≈˚ — )for ° d ONLN d2 — Δ › Î ( ⁄ ΔMacintos pÄ ° d ONLN d: — Ï › ¸ )&h W . ° d ONLN d= — ˝ › )ith P  ° d ONLN dB — ›) )owerP p` ° d ONLN dG —* ›0 )C ‡ ° d ONLN dH —1 ›3 ).
¯ )@or information about debugging and measuring the performance of ° d ONLN dÓ
Δc ( Δ"PowerPC applications, see the book V@ ° d ONLN d
df )û ÷@ ° d ONLN d
fã )Macintos Δ¿ ° d ONLN d
åì )&h F¿ ° d ONLN d
î” )Debugger Refer Y ° d ONLN d)
”‰ )?ence ¡@ ° d ONLN d-
‰Ê ).
° d ONLN d/" ∫) ø (( ∫n
° d ONLN d1 Δ+ À ) F ° d ONLN d2 Ã+f )!or information about performing fl @ ° d ONLN dT f+
)ö%oating-point calculations in PowerPC ° d ONLN dy+ Δ7: (4 Δapplications, see the book £@ ° d ONLN dî+:7’ )t"Inside Macintosh: PowerPC Numerics ˘Ä ° d ONLN d∂+’7◊ )õ.
° d ONLN d∏@ ∫G ø (F ∫n
° d ONLN d∫= ΔI À ) F ° d ONLN dª= ÃI )For information about building PowerPC applications and other kinds of ° d ONLN dI ΔU (R ΔPowerPC softwar ¿ ° d ONLN dIU )Ne ·` ° d ONLN dIUå ) for Macintosh computers, Ä ° d ONLN d*IçUü )u see —¿ ° d ONLN d/IüUœ ) Building Pr ≥@ ° d ONLN d:IœU¸ )0 ograms for ° d ONLN dEU Δa ¸ (^ Δ Macintosh W . ° d ONLN dPU ˝a
)7ith …@ ° d ONLN dTU
a) )
PowerP p` ° d ONLN dZU*a0 ) C ‡ ° d ONLN d[U1a3 ).
Format of a T ™∫ ° d ONLN dk ßí )_ypical Chapter ˇˇˇˇˇˇ V˛ (ç0
° d ONLN d{£ ∫Øê (¨ ∫1Almost all chapters in this book follow a standar ’` ° d ONLN d¨£êا )÷d str œ ° d ONLN d±£§Øª )uctur U ° d ONLN d∂£ºØ )e. For example, the ° d ONLN d ∞ ∫º≥ (π ∫5chapter “Mixed Mode Manager” contains these sections:
° d ONLN d Δ ∫Õ ø *n
° d ONLN d√ Δœ À ) “ ° d ONLN d√ Àœ\ ) About the Mixed Mode Manager {† ° d ONLN d √\œ )ë).” This section describes the Mixed Mode ° d ONLN dHœ Δ€ Ì (ÿ ΔManager T† ° d ONLN dOœ Ì€ Ú )'. ' ° d ONLN dQœ Ú€ ¯ )Y ÁÄ ° d ONLN dRœ ˜€) ) ou should r ∏@ ° d ONLN d]œ*€˘ )30ead this section for a general understanding of ° d ONLN dé€ ΔÁˇ (‰ ΔAwhat the Mixed Mode Manager does and when you might need to call ° d ONLN d–Á ΔÛ ˜ *
it explicitly ʆ ° d ONLN d›Á ˆÛ ¯ )0.
° d ONLN dfl¸ ∫ ø ( ∫n
° d ONLN d·˘ ΔZ ) “Using the Mixed Mode Manager ∫‡ ° d ONLN d˛˘Z§ )î.” This section pr Ç ° d ONLN d˘•ˇ )Kovides detailed instr û ° d ONLN d%˘ˇ )Zuc- ° d ONLN d) Δz ( Δ%tions on using the Mixed Mode Manager @ ° d ONLN dNy~ )≥. ¬† ° d ONLN dP~Ñ )Y É ° d ONLN dQÑ∂ ) ou should r S‡ ° d ONLN d\∑ )3ead this section if ° d ONLN dp Δ N ( Δ you need to use the services pr u ° d ONLN dèN )à ovided by the Mixed Mode Manager ˛¿ ° d ONLN dØÔ Ò )°.
° d ONLN d±& ∫- ø (, ∫n
° d ONLN d≥# Δ/G ) “Mixed Mode Manager Refer '‡ ° d ONLN dÃ#H/¶ )Çence.” This section pr √‡ ° d ONLN d‚#¶/¯ )^ovides a complete ° d ONLN dÙ/ Δ; … (8 Δr E ° d ONLN dı/ ; ⁄ )efer Ò ° d ONLN d˘/ ⁄;[ ) ence to the constants, data str û† ° d ONLN d/\;s )Çuctur $Ä ° d ONLN d /t;ô ) es, and r ]@ ° d ONLN d&/ô;≈ )%
outines pr #¿ ° d ONLN d0/Δ; )-ovided by the ° d ONLN d>; ΔG( (D ΔMixed Mode Manager ê` ° d ONLN dP;(GH )b. Each r 2¿ ° d ONLN dX;IG¸ )!)outine description also follows a standar FÄ ° d ONLN dÅ;¸G )≥d ° d ONLN dÉG ΔS (P Δformat, which pr · ° d ONLN dìGSA )J esents the r Ø@ ° d ONLN düGBS )2-outine declaration followed by a description ° d ONLN dÕS Δ_< (\ Δof every parameter of the r Å` ° d ONLN dËS<_| )voutine. Some r [† ° d ONLN dˆS|_¸ )@ outine descriptions also give ° d ONLN d_ Δkë (h Δ/additional descriptive information, such as cir † ° d ONLN dC_ëk )Àcumstances under which you ° d ONLN d^k Δw (t Δcannot call the r Æ@ ° d ONLN dok w: )F outine or r ¿ ° d ONLN dzk;wn )/ esult codes.
° d ONLN dáÄ ∫á ø (Ü ∫n
° d ONLN dâ} Δâw ) "“Summary of the Mixed Mode Manager '¿ ° d ONLN d´}wâ¡ )±.” This section pr Ó‡ ° d ONLN dΩ}¡â˙ )J
ovides the C ° d ONLN d â Δïb (í Δ&interfaces for the constants, data str fl‡ ° d ONLN dâbïy )úuctur e¿ ° d ONLN dıâzïã )es, r 1` ° d ONLN d˙âåï» )outines, and r ‚‡ ° d ONLN dâ»ï˚ )< esult codes ° d ONLN dï Δ° (û Δ&associated with the Mixed Mode Manager ∞¿ ° d ONLN d:ï°Ñ )π. ˇX @ ˇ ˇˇˇˇ @
° d ONLN d) ¯ ú Ï ( úAll code listings, r ~ ° d ONLN d= ¯ Ï" )P eserved wor fi ° d ONLN dH ¯"æ )6$ds, and the names of actual data str ’ ° d ONLN dl ¯æ’ )úuctur Z‡ ° d ONLN dq ¯÷‰ )es, . ° d ONLN du ú — ( ú constants, fi ° d ONLN dÇ —9 )5elds, parameters, and r R` ° d ONLN dô9e )h
outines ar $¿ ° d ONLN d£eæ ),e shown in Courier ( ,
Courier $¿ ° d ONLN d∑æÓ )Ythis is ° d ONLN dø ú Δ ( úCourier ° d ONLN dΔ Δ Õ )*). . ° d ONLN d…$ ú0 ¶ (- úW ï ° d ONLN d $ •0 Æ ) or œÄ ° d ONLN dÃ$ Æ0 ˚ ) ds that appear in ¯† ° d ONLN dfi$ ˚0" )Mboldface g ° d ONLN dÊ$#0. )( ar ¨ ° d ONLN dÈ$.0¥ ) e key terms or concepts and ar ˘‡ ° d ONLN d$¥0à )Üe defi 5† ° d ONLN d
ˇˇ‹. ˇ◊ ° d ONLN døm ú| § (x úT $é ° d ONLN d¿m §| ˜ )
ypes of Notes ˇˇˇˇˇˇ €r (x0
° d ONLN dœÉ úè ∞ (å úTher ¿ ° d ONLN d”É ±è ¡ )e ar ` ° d ONLN d◊É ¡èL )!e several types of notes used in ¡@ ° d ONLN d¯ÉLèë )ãInside Macintosh £@ ° d ONLN dÉíèî )F.
⁄ *˯ 4€ *˯ ° d ONLN dÆ€ ú„ ª (· úIMPORT Ä ° d ONLN d¥€ ª„ À ) ANT
ˇ·ˇ‚7^
° d ONLN d∏Ê úÚ £ (Ô úA ∫† ° d ONLN dπÊ £Ú° )> note like this contains information that is essential for an ° d ONLN d˜Ú ú˛ò (˚ ú7understanding of the main text. (An example appears on <† ° d ONLN d.Úô˛∞ )˝page Ä ° d ONLN d3Ú±˛√ )1-19 k` ° d ONLN d7Ú√˛» ).)
?@ ° d ONLN d:ıŒ˝’ ) s
*¯ 4 *¯
° d ONLN d<
à ê ( às
° d ONLN d= ú • )W úÄ ° d ONLN d> • – ) ARNING
ˇ·ˇ‚7^
° d ONLN dE ú# ¶ ( úW ï ° d ONLN dF •#G ) 'arnings like this indicate potential pr *‡ ° d ONLN dmH#’ )£ oblems that you should be awar …@ ° d ONLN dã’#‹ )çe ° d ONLN dç# ú/O (, ú)of as you design your application. Failur ^† ° d ONLN d∂#O/ø )≥e to heed these warnings ° d ONLN d–/ ú; ª (8 úcould r ∂ ° d ONLN d◊/ ª;h ) *esult in system crashes or loss of data. ( D† ° d ONLN d/i;‘ )ÆAn example appears on ° d ONLN d; úG ≥ (D úpage Z‡ ° d ONLN d ; ¥G ¡ )1-8 Æ¿ ° d ONLN d ; ¡G Δ )
.)
dž ° d ONLN d"> ÃF ” ) s
k *r¯ 4l *r¯ m úm(
ˇ·ˇ‚7^
ˇˇ‹. ˇ◊ ° d ONLN d$\ úk (g úBit Numbering and W ö* ° d ONLN d7\ kP )Çord Size ˇˇˇˇˇˇ €r )“0
° d ONLN dAr ú~ ı ({ úThis book departs fr ㆠ° d ONLN dUr ı~ç )Y!om the conventions followed in pr ¶` ° d ONLN dvrç~¨ )òevious 8@ ° d ONLN d}r≠~Ú ) Inside Macintosh @ ° d ONLN dçrÛ~ı )F ° d ONLN dé úã « (à ú
books in r =Ä ° d ONLN dò »ã € ),egar [@ ° d ONLN dú €ã¿ )5d to the numbering of bits within a range of data. Pr ° d ONLN d—¡ãÊ )Êeviously ㆠ° d ONLN dŸÂãÍ )$, ° d ONLN d€å úòc (ï ú/for example, the bits in a 32-bit data type wer $ ° d ONLN d
ådòé )»e number 0Ä ° d ONLN dåéòƒ )*ed 0 to 31, fr f† ° d ONLN d åƒò˜ )6 om right to ° d ONLN d,ô ú• ™ (¢ úleft »@ ° d ONLN d0ô ™• Ê ), as shown in Î@ ° d ONLN d>ô Ê• ˛ )<Figur æ ° d ONLN dCô ˛• )e P-1 e ° d ONLN dHô•w ) on the following page ì¿ ° d ONLN d^ôw•y )c. ¿ ° d ONLN d_ôz•¡ ) The least signifi ˚‡ ° d ONLN dqô¡•ˆ )Gcant bit of a ° d ONLN d¶ ú≤ (Ø ú32-bit data type was addr ° d ONLN dò¶
≤£ )q#essed as bit 0, and the most signifi 8‡ ° d ONLN dº¶£≤⁄ )ñ
cant bit was ° d ONLN d…≥ úø ± (º úaddr |Ä ° d ONLN dÕ≥ ±øt )-essed as bit 31. This convention was in accor ˇ ° d ONLN d˙≥tø‡ )√dance with that used by ˇ∂z @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ ∫˙ , Palatino
. Ñ` (·xiii
3, Ã ( # ∫PREF N )3ACE 4 ^ H¿
° d ONLN d \ ∫ h ’ ( e ∫Motor Á† ° d ONLN d \ ’ hà )ola in the books documenting their 680x0 family of micr ¬ ° d ONLN d < \à h€ )˜opr ˛† ° d ONLN d ? \€ h )ocessors (for ° d ONLN d M i ∫ u Ù ( r ∫
example, the W¿ ° d ONLN d Z i ı uP );MC68040 32-Bit Micr ˝† ° d ONLN d m iP u] )[opr #‡ ° d ONLN d p i^ uê ) ocessor User ı@ ° d ONLN d | iê uí )2’ /‡ ° d ONLN d } iì uπ )s Manual …¿ ° d ONLN d Ö iπ uæ )&).
ï H ¶ 4 ñ H ¶ ñ H ñ ‘
ˇ·ˇ‚7^ , Helvetica
° d ONLN d à ã ∫ ñ Â ( ì ∫
Figure P-1 ° d ONLN d ì ã ¸ ñM )B680x0 bit numbering
° d ONLN d ® ∫
y (
∫/In this book, the bits in a 32-bit data type ar ∑‡ ° d ONLN d ◊y
£ )øe number ƒ@ ° d ONLN d fl£
Ÿ )*ed 0 to 31, fr ˙` ° d ONLN d ÌŸ
)6 om left to ° d ONLN d ¯ ∫ ( ∫right. The most signifi ˝Ä ° d ONLN d∑ )a&cant bit of a 32-bit data type is addr ¿ ° d ONLN d5∏
)ùessed as bit 0, and ° d ONLN dI ∫' ¸ ($ ∫the least signifi ¿ ° d ONLN dZ ˝'? )Ccant bit is addr ‚ ° d ONLN dj>' )A/essed as bit 31. This convention, illustrated i >@ ° d ONLN dô' )√n ° d ONLN dõ( ∫4 “ (1 ∫Figur R¿ ° d ONLN d†( “4 Á )e P-2 ˘‡ ° d ONLN d•( Á4 È ), y‡ ° d ONLN d¶( Í4 ) is in accor Ù ° d ONLN d≤(4˚ ).1dance with the bit-numbering conventions used by ° d ONLN d„5 ∫A ’ (> ∫Motor Á† ° d ONLN dË5 ’A’ )ola in the books documenting the PowerPC family of micr q` ° d ONLN d 5÷A (>÷opr Æ ° d ONLN d"5ÂA ) ocessors ° d ONLN d+B ∫N (K ∫(for example, the Á† ° d ONLN d=BNn )MPowerPC 601 RISC Micr Û† ° d ONLN dRBnN{ )gopr ‡ ° d ONLN dUB|NÆ ) ocessor User Î@ ° d ONLN daBÆN∞ )2’ %‡ ° d ONLN dbB±N◊ )s Manual ø¿ ° d ONLN djB◊N‹ )&).
)z3, this book generally uses bytes to give the sizes ° d ONLN d7¨ ∫∏ (µ ∫of objects in memory ›` ° d ONLN dK¨∏ )[.
H 4 H ∫F
ˇ·ˇ‚7^
° d ONLN d& ∫ ‚ ( ∫ Table P-1 ° d ONLN d0 ¯c )>Sizes of memory operands ° d ONLN dI$ ∫/ Ã (, ∫Size –¡ ° d ONLN dN$ ı/D );680x0 terminology Û ° d ONLN d`$]/∫ )hPowerPC terminology
° d ONLN du5 ∫A — (> ∫8 bits –¡ ° d ONLN d|5 ıA );Byte Û ° d ONLN dÅ5]Ap )hByte ° d ONLN dáG ∫S ÿ (P ∫2 bytes –¡ ° d ONLN dèG ıS ˇ );W ¡ ° d ONLN dêG ˛S ) or A ° d ONLN díGS )
d Û ° d ONLN dîG]SÑ )UHalf wor í< ° d ONLN dúGÖSã )(d ° d ONLN düY ∫e ÿ (b ∫4 bytes –¡ ° d ONLN dßY ıe );Long wor ‘ ° d ONLN dØY e& )+d Û ° d ONLN d±Y]eg )=W ° d ONLN d≤Ygep )
or Bú ° d ONLN d¥Ypev ) d ° d ONLN d∑k ∫w ÿ (t ∫8 bytes –¡ ° d ONLN døk ıw );N/A Û ° d ONLN d√k]wë )h
Double wor x ° d ONLN dÕkíwò )5d ° d ONLN d–} ∫â › (Ü ∫16 bytes –¡ ° d ONLN dŸ} ıâ );N/A Û ° d ONLN d›}]âä )hQuad wor \ ° d ONLN dÂ}ãâë ).d
ˇ ˇ ˇ ˇ ˇ ˇ˛ ˇ˙ ˇ ˇ˝ ˇˇ ˇ ˇ¸ ˇ ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇˇ ˇ¸ ˇˇ ˇˇ ˇ ˇ ˇ ˇˇ˛ ˇ˚ ˇ ˇ ˇ ˇ¸ ˇ ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇˇ ˇ˝ ˇ ˇ ˇˇ˛ ˇˇ˛ ˇˇ ˇÅ Å ı ≠È ˛ˇ¸ ˇ˝ ˇˇ ˇ ˇ ˇ ˇˇ ˛ˇ˝ ˛ˇ˛ ˚ˇ ˛ˇ ˇ˚ ˇˇ˛ ˇˇ¸ ˇˇ˚ ˛ˇ˝ ˇˇ˝ ˇˇ ˇ ˇˇ ˇ ˛ˇ˚ ˇ ˇ˝ ˇˇ ˇˇ ˇ ˛ˇ ˇ¸ ˇˇ˝ ˇˇ˚ ˛ˇ˝ ˇˇ˝ ˇˇ ˇ ˇˇ ˇ ˛ˇ˚ ˇˇ ˇ ˛ˇ ˛ˇ ˛ˇÅ Å Ù ô ˇ… ˛Ô ˇ— ˛Å Å Ò ô ˇ ˇÓ ˇ— ˇÅ Å Ò ö ˛ˇ∏ ˛ˇ” ˛ˇÅ Å Ú Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã  ˇˇÚ ˇˇˆ ˇ˛ˇ ˇ— ˛ˇˇÅ Å Å ˝ ò @ @ˆ @ˆB FÇ< ˛ D˚ Ä– ˛ Ñ˛ Ä– ˛ $Ûƒ`Äe≥ÃΩñX`— ˛ $I$ë íI$íH$†— ˛ |I%!I$îà%– ˛ Dä)¡í)'I– ˛ ÑíK$ñIlPK — Œ„ч‡ƒõÜìêáLƒ— ˛ ˝ ˛ Äœ ˛ ˝ Œ ˛ é˝ À ˛
ˇ ˇ ˇ ˇ˘ ¸ˇ˛ ˇ˛ ˇ¸ ˇ˛ ˇ ˇ ˇ˛ ˇ ˇ ˇ¸ ˇ ˇ˛ ˇ ˇÅ Å è cË ˇ¸ ˛˛ˇ ˇ ˇ˝ ˇ ˛˝ ˇ˝ ˇ˛ ˇˇ˛ ˇ˛ˇ¯ ˇ˛ ˇ ˇ˛ ˇ˚ ˇ ˛˛ ˛ ˇ˝ ˇ˛ˇ ˛˝ ˇ˛ ˇ˛ ˇ ˇÅ Å é jË ˇ˝ ˇ ˇ˛ ˇˇ ˇˇ ˇ˛ ˇˇ˝ ˇ˛ ˇ˝ ˇ˛ ˇˇ˛ ˇ˚ ˇ˝ ˇ ˇ˛ ˇ ˇ˝ ˇ ˇ ˇˇ ˇ˝ ˇ˛ ˇˇ ˇ ˇ ˇ ˇ ˇ ˇÅ Å é [È ˚ˇ˛ ˛ˇ ˇ ˇ˝ ˇ˚ ˝ˇ¸ ˛ˇ ˛ˇ ˇ˛ ˛ˇ ˛ˇ ˇ˝ ˇ˚ ˇˇ ˇ ˛ˇ¸ ˛ˇ ˇˇ˛ ˇ˛ ˇˇ˛ ˇÅ Å é ” ˇË ˇÅ Å Å ‘ ÷ ˇ ˇË ˇÅ Å Å ”
÷ ˇˇÅ Å Å ∏ Á ˇ˛˛ˇ ˇˇ‘ ˇˇ˚ ˛ˇÅ Å Å Ê "Ê ˇ ˇ˛ ˇ’ ˇ ˇ˝ ˇ˛ ˇÅ Å Å Á #Ê ˇ ˇ˛ ˇÙ ˇÙ ˇÓ ˇ˘ ˇÅ Å Å Á BÁ ˇ ˛˛ ˛ ˇˇ ˇ ˛ˇ ˛ˇ˛ ˇˇ˛ ˇ˛ ˇˇ˛ˇˇ ˛ˇ ˛ ˇˇ˘ ˛˘ ˇÅ Å Å Ê @Á ˇ ˇ˛ ˇ ˇ ˇ ˇ ˇ ˇ ˇ˝ ˇ ˇ ˇ ˇ ˇ ˇ˘ ˇˇ˘ ˇÅ Å Å Â ?Á ˇ ˇ˛ ˇ ˇ ˇ ˇ˝ ˇ ˇ˛ ˇ˛ ˇ ˇ ˇ˛ ˇ ˇ˜ ˇ˚ ˇÅ Å Å ‰ >Ë ˇ ˇ˛ ˇ ˛ ˇ˝ ˛ ˇ ˇ˝ ˇ ˇ ˇ ˛˛ ˛ ˇˆ ˇ¸ ˛Å Å Å „ FË ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇ ˇ ˇˇ˝ ˇ ˇ ˇˇ ˇˇ ˇ ˇ˙ ˇ ˇ¸ ˇ˝ ˇÅ Å Å Á BÈ ˛ˇ ˇ˛ ˇ ˇˇ ˇ ˛ˇ˛ ˇ ˇ¸
ˇˇ ˇ ˇ ˇˇ˛ ˇ˘ ˇˇ˛ ˇ ¸ˇÅ Å Å Ê Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ ÄˆÇ F¬< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ¬ Ffi< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆfi F < ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉ F^< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆ^ Fz< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆfi F < ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ F^< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ^ Fz< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆz F∫< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉ∫ F˙< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆ˙ F< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆz F∫< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ∫ F˙< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:t / Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ˙ F< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆ FV< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ ĈV Fñ< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆñ F≤< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:x /
˛êêê @ˆ FV< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:t / Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ ĈV Fñ< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:x / Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆñ F≤< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã
ˇ ˇ ˇ ˇ ˇ ˇ˛ ˇ˙ ˇ ˇ˝ ˇˇ ˇ ˇ¸ ˇ ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇˇ ˇ¸ ˇˇ ˇˇ ˇ ˇ ˇ ˇˇ˛ ˇ˚ ˇ ˇ ˇ ˇ¸ ˇ ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇˇ ˇ˝ ˇ ˇ ˇˇ˛ ˇˇ˛ ˇˇ ˇÅ Å ı ≠È ˛ˇ¸ ˇ˝ ˇˇ ˇ ˇ ˇ ˇˇ ˛ˇ˝ ˛ˇ˛ ˚ˇ ˛ˇ ˇ˚ ˇˇ˛ ˇˇ¸ ˇˇ˚ ˛ˇ˝ ˇˇ˝ ˇˇ ˇ ˇˇ ˇ ˛ˇ˚ ˇ ˇ˝ ˇˇ ˇˇ ˇ ˛ˇ ˇ¸ ˇˇ˝ ˇˇ˚ ˛ˇ˝ ˇˇ˝ ˇˇ ˇ ˇˇ ˇ ˛ˇ˚ ˇˇ ˇ ˛ˇ ˛ˇ ˛ˇÅ Å Ù ô ˇ… ˛Ô ˇ— ˛Å Å Ò ô ˇ ˇÓ ˇ— ˇÅ Å Ò ö ˛ˇ∏ ˛ˇ” ˛ˇÅ Å Ú Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã  ˇˇÚ ˇˇˆ ˇ˛ˇ ˇ— ˛ˇˇÅ Å Å ˝ ò @ @ˆ @ˆ F[< ˛ D˚ Ä– ˛ Ñ˛ Ä– ˛ $Ûƒ`Äe≥ÃΩñX`— ˛ $I$ë íI$íH$†— ˛ |I%!I$îà%– ˛ Dä)¡í)'I– ˛ ÑíK$ñIlPK — Œ„ч‡ƒõÜìêáLƒ— ˛ ˝ ˛ Äœ ˛ ˝ Œ ˛ é˝ À ˛
ˇ ˇ ˇ ˇ˘ ¸ˇ˛ ˇ˛ ˇ¸ ˇ˛ ˇ ˇ ˇ˛ ˇ ˇ ˇ¸ ˇ ˇ˛ ˇ ˇÅ Å è cË ˇ¸ ˛˛ˇ ˇ ˇ˝ ˇ ˛˝ ˇ˝ ˇ˛ ˇˇ˛ ˇ˛ˇ¯ ˇ˛ ˇ ˇ˛ ˇ˚ ˇ ˛˛ ˛ ˇ˝ ˇ˛ˇ ˛˝ ˇ˛ ˇ˛ ˇ ˇÅ Å é jË ˇ˝ ˇ ˇ˛ ˇˇ ˇˇ ˇ˛ ˇˇ˝ ˇ˛ ˇ˝ ˇ˛ ˇˇ˛ ˇ˚ ˇ˝ ˇ ˇ˛ ˇ ˇ˝ ˇ ˇ ˇˇ ˇ˝ ˇ˛ ˇˇ ˇ ˇ ˇ ˇ ˇ ˇÅ Å é [È ˚ˇ˛ ˛ˇ ˇ ˇ˝ ˇ˚ ˝ˇ¸ ˛ˇ ˛ˇ ˇ˛ ˛ˇ ˛ˇ ˇ˝ ˇ˚ ˇˇ ˇ ˛ˇ¸ ˛ˇ ˇˇ˛ ˇ˛ ˇˇ˛ ˇÅ Å é ” ˇË ˇÅ Å Å ‘ ÷ ˇ ˇË ˇÅ Å Å ”
÷ ˇˇÅ Å Å ∏ Á ˇ˛˛ˇ ˇˇ‘ ˇˇ˚ ˛ˇÅ Å Å Ê "Ê ˇ ˇ˛ ˇ’ ˇ ˇ˝ ˇ˛ ˇÅ Å Å Á #Ê ˇ ˇ˛ ˇÙ ˇÙ ˇÓ ˇ˘ ˇÅ Å Å Á BÁ ˇ ˛˛ ˛ ˇˇ ˇ ˛ˇ ˛ˇ˛ ˇˇ˛ ˇ˛ ˇˇ˛ˇˇ ˛ˇ ˛ ˇˇ˘ ˛˘ ˇÅ Å Å Ê @Á ˇ ˇ˛ ˇ ˇ ˇ ˇ ˇ ˇ ˇ˝ ˇ ˇ ˇ ˇ ˇ ˇ˘ ˇˇ˘ ˇÅ Å Å Â ?Á ˇ ˇ˛ ˇ ˇ ˇ ˇ˝ ˇ ˇ˛ ˇ˛ ˇ ˇ ˇ˛ ˇ ˇ˜ ˇ˚ ˇÅ Å Å ‰ >Ë ˇ ˇ˛ ˇ ˛ ˇ˝ ˛ ˇ ˇ˝ ˇ ˇ ˇ ˛˛ ˛ ˇˆ ˇ¸ ˛Å Å Å „ FË ˇ ˇ ˇ ˇ ˇˇ ˇ ˇˇ ˇ ˇ ˇˇ˝ ˇ ˇ ˇˇ ˇˇ ˇ ˇ˙ ˇ ˇ¸ ˇ˝ ˇÅ Å Å Á BÈ ˛ˇ ˇ˛ ˇ ˇˇ ˇ ˛ˇ˛ ˇ ˇ¸
ˇˇ ˇ ˇ ˇˇ˛ ˇ˘ ˇˇ˛ ˇ ¸ˇÅ Å Å Ê Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ[ Fõ< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆõ F∑< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆ∑ F˜< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉ˜ F7< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆ7 FS< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆ∑ F˜< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ˜ F7< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ7 FS< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆS Fì< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉì F”< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆ” FÔ< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆS Fì< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉì F”< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ” FÔ< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆÔ F/< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉ/ Fo< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆo Fã< ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆÔ F/< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H Å:x /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ/ Fo< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H Å:t /Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆo Fã< ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ˇ6 @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ *˙¯ , Palatino
. (· *xiv
3, à ( # úPREF N )3ACE 4 ^ *¿¯
k * r¯ 4 l * r¯ m ú m(
ˇ·ˇ‚7^ , Helvetica
ˇˇ‹. ˇ◊ ° d ONLN d \ ú ka ( g ú Assembly-Language Information ˇˇˇˇˇˇ €r ( g0
les; the thir ö@ ° d ONLN dW' ”3î )1,d column indicates the C data type of that fi C¿ ° d ONLN dÑ'ï3Ÿ )¬eld. The fourth ° d ONLN dî4 ú@ … (= ú column pr A¿ ° d ONLN dù4 @ã )..ovides a brief description of the use of the fi ±¿ ° d ONLN dÃ4ã@· )¡eld. For a complete ° d ONLN d‡A úM ¯ (J údescription of each fi ¬¿ ° d ONLN dˆA ¯M” )\3eld, see the discussion that follows the parameter ° d ONLN d*N úZå (W ú8block or the description of the parameter block in the r Ä ° d ONLN dbNçZù )Òefer ∞† ° d ONLN dfNùZ‡ )ence section of ° d ONLN dw[ úg Õ (d ú the chapter b` ° d ONLN dÇ[ Õg œ )1.
° d ONLN dû™ ú∂ Ú (≥ úThe system softwar ↠° d ONLN d∞™ Ú∂ ˝ )Ve r ò@ ° d ONLN d≥™ ˝∂å ) !outines described in this book ar +‡ ° d ONLN d‘™ç∂‡ )êe available using C ° d ONLN dÁ™‡∂‚ )S ° d ONLN dÈ∑ ú√ñ (¿ ú7or assembly-language interfaces. How you access these r u` ° d ONLN d ∑ñ√· )˙outines depends ° d ONLN d1ƒ ú– (Õ úon the development envir yÄ ° d ONLN dIƒ–N )r
onment you ar BÄ ° d ONLN dVƒO–· )A e using. This book shows system ° d ONLN dv— ú› Ω (⁄ úsoftwar ‰¿ ° d ONLN d}— Ω› » )!e r Û` ° d ONLN dÄ— »›
) outines in their d‡ ° d ONLN dë—› )FC {‡ ° d ONLN dí—›¶ )! interface using the Macintosh Pr ‡Ä ° d ONLN d≥—¶›‘ )ëogrammer ˘` ° d ONLN dª—’›fi )/’s ° d ONLN dæfi úÍ ¶ (Á úW ï ° d ONLN døfi •Í Ó ) orkshop (MPW). ° d ONLN dŒ ú¸% (˘ ú!All code listings in this book ar r¿ ° d ONLN dÔ%¸ )â0e shown in C (except for listings that describe ˇˇ≈~ ° d ONLN d ˝ ú ü ( úr E ° d ONLN d ˝ † ∏ )esour ç@ ° d ONLN d%˝ ∏ )
ces, which ar &| ° d ONLN d2˝ Ò ¯ )99e shown in Rez-input format). They show methods of using ° d ONLN dk
ú √ ( ú various r ˇ‡ ° d ONLN dt
√ )'Foutines and illustrate techniques for accomplishing particular tasks. ° d ONLN d∫ ú#fi ( úHAll code listings have been compiled and, in most cases, tested. However y† ° d ONLN dfi#„ ( fi, ° d ONLN d$ ú0‰ (- úGApple Computer does not intend that you use these code samples in your ° d ONLN dK1 ú= “ *
application. @ ° d ONLN dX1 ”= Ÿ )7Y …¿ ° d ONLN dY1 ÿ= ˝ )ou can fi î¿ ° d ONLN db1 ˛= )&<nd the location of this book’s code listings in the list of ° d ONLN dû> úJ ¢ (G úfi å¿ ° d ONLN d†> ¢J ± )gur Ë ° d ONLN d£> ±J )es, tables, and listings. ° d ONLN dΩP ú\ ¢ (Y úT µ¿ ° d ONLN dæP °\V ))o make the code listings in this book mor Ÿ† ° d ONLN dÁPV\a )µe r Ë@ ° d ONLN dÍPa\Õ ) eadable, only limited err ˚¿ ° d ONLN dPÕ\ÿ )lor ° d ONLN d] úi Ú (f úhandling is shown. ¿ ° d ONLN d] Ûi ˘ )WY ‘@ ° d ONLN d] ¯iÈ )5ou need to develop your own techniques for detecting ° d ONLN dOj úv Ê (s úand handling err fi ° d ONLN d_j Êv Û )Jors É@ ° d ONLN dbj Ùv ˆ ). ° d ONLN dd| úàk (Ö ú0This book occasionally illustrates concepts by r ч ° d ONLN dî|kà{ )œefer 1 ° d ONLN dò||àÁ )ence to a sample applica » ° d ONLN d∞|ÁàÍ )k- ° d ONLN d≤â úï à (í ú tion called ° d ONLN dæâ Õï Ë )1SurfW ¿ ° d ONLN d√â Ëï ˘ )riter ‰¿ ° d ONLN d»â ˘ïñ )$ and a sample import library called s ° d ONLN dÏâóïÆ )ûSurfT <@ ° d ONLN dÒâÆïΩ )ools «† ° d ONLN dıâΩï‰ )
; these ar † ° d ONLN dˇâ‰ïÎ )'e ° d ONLN dñ ú¢ ‘ (ü ú
not actual pr rÄ ° d ONLN dñ ‘¢ ˇ )8
oducts of eÄ ° d ONLN dñ ˇ¢J )+Apple Computer ° d ONLN d&ñJ¢_ )K, Inc. , Symbol ° d ONLN d ä ´ ú ∂ ¶ ( ¥ ú´ ,
° d ONLN d ô ∫ • ◊ ( ¢ ∫APDA H¿ ° d ONLN d ô ◊ • „ ) is ¿ ° d ONLN d ô „ •O ) Apple’s worldwide sour ¯ ° d ONLN d 4 ôN •å )kce for over thr ¿ ° d ONLN d C ôç •¥ )?ee hundr º† ° d ONLN d K ô¥ •˛ )'ed development ° d ONLN d Z ¶ ∫ ≤ ( Ø ∫tools, technical r w¿ ° d ONLN d l ¶ ≤ )Hesour ¿ ° d ONLN d q ¶ ≤\ )ces, training pr µ† ° d ONLN d Å ¶\ ≤˚ )B#oducts, and information for anyone ° d ONLN d § ≥ ∫ ø Œ ( º ∫inter
ools Catalog ~ ° d ONLN d ¿M Ãó )4featuring all curr @ ° d ONLN d# ¿ò À )Kent versions of Ù` ° d ONLN d3 ¿⁄ Ø )BApple ° d ONLN d9 Õ ∫ ŸÄ ( ÷ ∫+development tools and the most popular thir È¿ ° d ONLN dd ÕÄ Ÿ˙ )Δd-party development tools. ° d ONLN d ⁄ ∫ Ê ≈ ( „ ∫Or ‡ ° d ONLN dÅ ⁄ Δ Ê ) dering is easy; ther ü@ ° d ONLN dï ⁄ Ê) )Se ar ≠‡ ° d ONLN dô ⁄) Ê˚ ).e no membership fees, and application forms ar Δ‡ ° d ONLN d« ⁄˚ Ê )“e not ° d ONLN dÕ Á ∫ Û Ω ( ∫r E ° d ONLN dŒ Á æ Û ’ )equir \@ ° d ONLN d” Á ’ Û1 )ed for most of our pr F@ ° d ONLN dË Á1 ÛS )\oducts. o‡ ° d ONLN d ÁS Ûp )"APDA 8† ° d ONLN dÙ Áp Û{ ) of T` ° d ONLN d˜ Á{ Û˛ ) fers convenient payment and ° d ONLN d Ù ∫ r ( ˝ ∫+shipping options, including site licensing. ° d ONLN d? ∫ ¿ *T µ¿ ° d ONLN d@ ø – )o or ¿ ° d ONLN dD – Î )der pr ‡ ° d ONLN dJ Ï' ) oducts or to r Ò‡ ° d ONLN dX&Δ ):#equest a complimentary copy of the Ç@ ° d ONLN d{«„ )°APDA w ° d ONLN d„Î ) T ˜ ° d ONLN dÅ͸ )ools ° d ONLN dÜ ∫ Ÿ ( ∫Catalog ó` ° d ONLN dç Ÿ )
, contact ° d ONLN dò% ∫1 ◊ (. ∫APDA H¿ ° d ONLN dú% ◊1 Ÿ ) ° d ONLN dû2 ∫> (; ∫Apple Computer (Ä ° d ONLN d¨2> )K, Inc. ° d ONLN d¥? ∫K ¿ (H ∫P ?† ° d ONLN dµ? øK ) .O. Box 319 ° d ONLN d¡L ∫X … (U ∫Buf … ° d ONLN dƒL …X Ì )falo, NY G† ° d ONLN dÃL ÓX )% 14207-0319 ° d ONLN d•‹ ∫Ë Ω ( ∫I fiÄ ° d ONLN d¶‹ ΩË ‡ )f you pr @ ° d ONLN dÆ‹ ·Ë )$ ovide commer ã ° d ONLN d∫‹ Ë; )?cial pr @ ° d ONLN d¡‹<ËÛ ) +oducts and services, call 408-974-4897 for ° d ONLN dÏÈ ∫ım (Ú ∫'information on the developer support pr ° d ONLN dÈnı¬ )¥ograms available fr ‹‡ ° d ONLN d&Ȭı“ )Tom H ° d ONLN d)È”ı )Apple. ° d ONLN d0˚ ∫ ( ∫For information o ® ° d ONLN dA˚
)Nn yÄ ° d ONLN dB˚ ) r æÄ ° d ONLN dD˚g )egistering signatur òÄ ° d ONLN dW˚g{ )Ses, fi ´‡ ° d ONLN d]˚{¢ )
le types, Y¿ ° d ONLN dg˚¢ )'Apple events, and other ° d ONLN d ∫= ( ∫ technical information, contact ° d ONLN dû ∫&! *Macintosh Developer T .@ ° d ONLN d≥!&k )gechnical Support ° d ONLN dƒ' ∫3 (0 ∫Apple Computer (Ä ° d ONLN d“'3 )K, Inc. ° d ONLN dŸ4 ∫@ ˚ (= ∫20525 Mariani +† ° d ONLN dÁ4 ˚@ )AA ‡ ° d ONLN dË4@1 ) venue, M/ û` ° d ONLN dÒ41@V )/S 303-2T ° d ONLN d˙A ∫M ˚ (J ∫
Cupertino, CA ¿ ° d ONLN dA ˚M( )A
95014-629 Û† ° d ONLN dA(M- )-9 ° d ONLN d◊^ ∫j ¿ (g ∫T µ¿ ° d ONLN dÿ^ øj Á )elephone j ° d ONLN d·^Gj√ )à 800-282-2732 (United States) j ° d ONLN d˛iGu™ * 800-637-0029 (Canada) j ° d ONLN dtGĬ * 716-871-6555 (International) ° d ONLN d2Ñ ∫ê … (ç ∫Fax j ° d ONLN d6ÑGêz )ç 716-871-651 Ö& ° d ONLN dAÑzêÅ )31 ° d ONLN dEî ∫† È (ù ∫ AppleLink j ° d ONLN dOîG†d )çAPDA ° d ONLN dU§ ∫∞ (≠ ∫America Online j ° d ONLN dd§G∞d )çAPDA ° d ONLN dj¥ ∫¿ Û (Ω ∫
CompuServe j ° d ONLN du¥G¿v )ç
76666,2405 ° d ONLN dŃ ∫– › (Õ ∫Internet j ° d ONLN däƒG–Δ )çAPDA@applelink.apple.com ˇ L @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 ^ *¿¯ ˇ
˙ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4⁄ ∫˙ , Helvetica
. (‡ ∫Contents , Palatino
, (‡ 1-1
3, à ( # ∫CHAPTER ÿ )h1 ˇˇˇˇˇˇ ( J H
Figure 1-0 * Listing 1-0 * T )able 1-0
ˇˇu÷ ˇÆ ( q H1 ° d ONLN d [ ∫ x ‰ )rIntr $» ° d ONLN d [ ‰ x‡ )*oduction to PowerPC
ó HI 4 ó HI 1 H1
° d ONLN d (6 ∫G ˘ (C ∫Contents
ˇ·ˇ‚7^
ˇˇu÷ ˇÆ ° d ONLN d x ∫ ïl ( é ∫System Softwar –$ ° d ONLN d & xl ïx )≤e
° d ONLN d 1X ∫du (a ∫&Overview of the PowerPC System Softwar ö¿ ° d ONLN d WXudy )ªe d` ° d ONLN d ZXédõ )1-4 ° d ONLN d ^e ∫q (n ∫The 68LC040 Emulator ¯@ ° d ONLN d te3q@ )y1-6 ° d ONLN d xr ƒ~ ({ ƒEmulator Operation ï† ° d ONLN d år1~> )m1-7 ° d ONLN d ê ƒã" (à ƒEmulator Limitations ;@ ° d ONLN d ¶7ãD )s1-8 ° d ONLN d ™å Œò ‰ (ï ŒCopr ”† ° d ONLN d Æå ‰ò )ocessors ¢ ° d ONLN d ∏å ò* )91-9 ° d ONLN d ºò Œ§ ‚ (° ŒInstr
‡ ° d ONLN d ¡ò „§ )uction T ° d ONLN d …ò§% )$imings M@ ° d ONLN d —ò9§F )21-9 ° d ONLN d ’• Œ± (Æ Œ
Deleted Instr ÓÄ ° d ONLN d ‚•±' )9uctions Ä ° d ONLN d Ε<±I )51-9 ° d ONLN d Ô≤ Œæ (ª ŒUnsupported Instr ˛¿ ° d ONLN d ≤ æZ )R
uction Featur œ ° d ONLN d
≤[æd );es ’† ° d ONLN d≤xæä ) 1-10 ° d ONLN dø ŒÀ ‚ (» ŒInstr
‡ ° d ONLN dø „À )
uction Caches ÷ ° d ONLN d*ø4ÀF )Q1-10 ° d ONLN d/À Œ◊  (‘ ŒAddr C¿ ° d ONLN d3À Ê◊ )ess Err ⁄¿ ° d ONLN d:À◊? )
or Exceptions Ò‡ ° d ONLN dIÀS◊e )P1-10 ° d ONLN dNÿ Œ‰ Ó (· ŒBus Err 3@ ° d ONLN dUÿ Ô‰+ )!
or Exceptions J` ° d ONLN ddÿ?‰L )P1-1 † ° d ONLN dgÿL‰Q )
1 ° d ONLN di ŒÒ] (Ó ŒMemory-Mapped I/O Locations 6† ° d ONLN dÜÂrÒ )§1-1 ˝‡ ° d ONLN dâÂ~ÒÉ ) 1 ° d ONLN dãÚ ∫˛ Ú (˚ ∫
Mixed Mode ;¿ ° d ONLN dóÚ˛ )M1-13 ° d ONLN dúˇ ƒ œ ( ƒCr \ ° d ONLN dûˇ œ ) oss-Mode Calls @ ° d ONLN dÆˇ' 9 )X1-14 ° d ONLN d≥ ƒ ( ƒRoutine Descriptors È ° d ONLN d» 0B )l1-15 ° d ONLN dÕ ƒ%/ (" ƒMemory Considerations ° d ONLN d‰D%V )Ä1-19 ° d ONLN dÈ& ∫22 (/ ∫The PowerPC Native Envir ô ° d ONLN d&22S )xonment ë@ ° d ONLN d &h2z )61-19 ° d ONLN d3 ƒ? Ú (< ƒ Fragments @ ° d ONLN d3? )C1-20 ° d ONLN d @ ŒL Ì (I ŒThe Str Ä ° d ONLN d%@ ÓL ) uctur ¢` ° d ONLN d*@LF )e of Fragments 4† ° d ONLN d:@[Lm )V1-22 ° d ONLN d?L ŒX) (U ŒImports and Exports ∑@ ° d ONLN dTL=XO )o1-23 ° d ONLN dYY Œe Á (b ŒThe T ÒÄ ° d ONLN d^Y Êe- )able of Contents Ø ° d ONLN dpYBeT )\1-26 ° d ONLN duf Œr (o ŒSpecial Routines y‡ ° d ONLN dáf+r= )]1-29 ° d ONLN dås Œ (| ŒFragment Storage @ ° d ONLN dûs1C )c1-30 ° d ONLN d£ Œã (à ŒExecutable Resour ˜† ° d ONLN d¥ ã, )Qces nÄ ° d ONLN dπAãS )"1-34 ° d ONLN dæå ƒò À (ï ƒC ó ° d ONLN døå Àò )alling Conventions ~` ° d ONLN d”å3òE )h1-41 ° d ONLN dÿô Œ•W (¢ Œ The 680x0 Calling Conventions b¿ ° d ONLN d˜ôl•~ )û1-42 ° d ONLN d¸¶ Œ≤h (Ø Œ The PowerPC Calling Conventions Ì ° d ONLN d ¶|≤é )Æ1-43 ° d ONLN d"≥ Œø (º ŒParameter Passing e ° d ONLN d5≥4øF )f1-47 ˇ8 @ ˇ ˇˇˇˇ @
ˇˇ—Ú ˇÆ ° d ONLN d 8 ä C+ ( @ ä'Introduction to PowerPC System Software ˇˇˇˇˇˇ ≠> ( @1
° d ONLN d ( \ ä h ( e ä This chapter is a general intr ° d ONLN d F \ hê )~ oduction to the system softwar lÄ ° d ONLN d d \ê h° )àe pr }@ ° d ONLN d h \° h¸ )ovided on PowerPC ° d ONLN d z i ä u ì ( r äpr G ° d ONLN d | i î u ¥ )
ocessor ´ ° d ONLN d É i ¥ u≤ ) 8-based Macintosh computers. It describes the mixed envir @ ° d ONLN d ª i≥ u· )ˇ onment pr Ä ° d ONLN d ƒ i· u ).
ovided by ° d ONLN d Œ v ä Çu ( ä/the 68LC040 Emulator and the Mixed Mode Manager t¿ ° d ONLN d ˝ vu Ç )Î . These two new system softwar Ö‡ ° d ONLN d v Ç )çe ° d ONLN d É ä è˛ ( å äVservices work together to allow existing 680x0 applications, extensions, drivers, and ° d ONLN ds ê ä ú ≈ *
( ¶ äQcomputers. The 68LC040 Emulator and the Mixed Mode Manager also make it possible ° d ONLN d ™ ä ∂ *
for parts of the system softwar $¿ ° d ONLN d7 ™ ∂' )áe to r k@ ° d ONLN d= ™' ∂ )5emain as 680x0 code, while other parts of the system ° d ONLN dr ∑ ä √ ´ ( ¿ äsoftwar ‰¿ ° d ONLN dy ∑ ´ √ ª )!e ar Û` ° d ONLN d} ∑ ª √ Δ )e r ° d ONLN dÄ ∑ « √L ) eimplemented (primarily for r +` ° d ONLN dù ∑L √ )Ö(easons of speed) as native PowerPC code. ° d ONLN dΔ … ä ’° ( “ ä>This chapter also describes the native PowerPC execution envir Ä ° d ONLN d …¢ ’» ( “¢onment. ö` ° d ONLN d …» ’ )&
Although the ° d ONLN d ÷ ä ‚ ì ( fl äpr G ° d ONLN d ÷ î ‚ )
Rocess-scheduling mechanism used for both native and emulated applications has not ° d ONLN dm „ ä Ô » ( Ï ächanged, the r CÄ ° d ONLN d{ „ … Ô )?
un-time envir ¶‡ ° d ONLN dà „ Ô¬ )<)onment for PowerPC applications is signifi "` ° d ONLN d≤ „√ ÔÏ )æ
cantly dif »@ ° d ONLN dº „Ï Ô¯ ))fer ™¿ ° d ONLN dø „¯ Ô ) ent ° d ONLN d√ ä ¸ ë ( ˘ äfr ò‡ ° d ONLN d≈ ë ¸ ∂ )om the r û` ° d ONLN dÕ ∂ ¸ Ú )%
un-time envir ¿ ° d ONLN d⁄ Û ¸ )==onment used for 680x0-based Macintosh applications. In cases ° d ONLN d ˝ ä † ( äwher 7 ° d ONLN d ˝ ° > )$e your application (or other softwar ú ° d ONLN d? ˝> L )ùe) r ˛† ° d ONLN dC ˝L ä )elies on featur Ä ° d ONLN dR ˝ã — )?es of the 680x0 r « ° d ONLN dc ˝— ˆ )Fun-time ° d ONLN dk
ä ° ( äenvir n† ° d ONLN dp
°å )4onment, you’ll need to modify your application befor ` ° d ONLN d§
çò )Ïe r ° d ONLN dß
ò ) ecompiling it as a PowerPC ° d ONLN d¬ ä#^ ( ä1application. For example, if your application dir c ° d ONLN dÛ^#‰ )‘ ectly accesses information stor v‡ ° d ONLN d‰# )Ü
ed in low ° d ONLN d $ ä0i (- ä3memory (such as system global variables) or in its <† ° d ONLN dO$i0£ )fl A5 world, yo K¿ ° d ONLN d[$£0Œ ): u might n ÉÄ ° d ONLN dd$Œ0Ô )+eed to r Ø` ° d ONLN dl$Ô0
)!ewrite ° d ONLN ds1 ä= ≥ (: ä
parts of y L† ° d ONLN d}1 ¥= )*our application to r o† ° d ONLN dë1 =› )U.emove the dependence on that information. See nÄ ° d ONLN dø1fi=ˆ )’“The ° d ONLN dƒ> äJ Ô (G äPowerPC Native Envir ]@ ° d ONLN dÿ> ÔJm )eonment” beginning on page ´† ° d ONLN dÚ>mJ )~1-19 ˇÄ ° d ONLN dˆ>Jœ ) for complete instr Õ ° d ONLN d >–J )Q uctions on ° d ONLN dK äW π (T ä doing this. ° d ONLN d ] äi ê *Y @Ä ° d ONLN d!] êi ¬ ) ou should r @ ° d ONLN d,] √iõ )32ead this chapter if you want your application to r † ° d ONLN d^]õiÌ )ÿun on PowerPC pr
° d ONLN dn]Ói )Socessor n ° d ONLN du]i ) - ° d ONLN dwj äv˝ (s äObased Macintosh computers, either under the 68LC040 Emulator or in the PowerPC ° d ONLN dΔw äÉ ø *
680x0 micr @ ° d ONLN d$´ ∫∑ … )0opr V‡ ° d ONLN d'´ …∑ È )ocessor + ° d ONLN d.´ È∑ Î ) . ° d ONLN d0Ω ä… ê (Δ äY @Ä ° d ONLN d1Ω ê… ◊ )ou should also r , ° d ONLN dAΩ ◊… )GBead this chapter for information about the PowerPC execution envir Ó‡ ° d ONLN dÉΩ… (Δon- ° d ONLN dá ä÷ • (” äment. ” ° d ONLN dç •÷) ) Although the existing softwar ÿÄ ° d ONLN d™ )÷ )Ñ#e development tools build your sour ”¿ ° d ONLN dÕ ÷ )°
ce code into ° d ONLN d⁄◊ ä„^ (‡ ä.executable PowerPC code that conforms to the r a‡ ° d ONLN d ◊^„u )‘equir y ° d ONLN d
◊u„· )ements of this new envir @ ° d ONLN d %◊‚„ )monment, ° d ONLN d -‰ äG (Ì ä)you might need to know about the native r æ‡ ° d ONLN d V‰GÉ )Ω
un-time envir "@ ° d ONLN d c‰Ñ )= onment for debugging purposes ° d ONLN d ÅÒ ä˝ (˙ äUor if your application uses external code modules. Otherwise, the new execution envir J@ ° d ONLN d ÷Ò˝ (˙on- ° d ONLN d ⁄˛ ä
) ( ä"ment should be completely transpar
† ° d ONLN d ¸˛*
ë )†ent to your application. ° d ONLN d
ä ê ( äY @Ä ° d ONLN d
ê )Vou should be able to accomplish much of the work involved in porting your application ° d ONLN d
l ä) ë (& äfr ò‡ ° d ONLN d
n ë) )Som the 680x0 platform to the PowerPC platform using the information in this chapter » ° d ONLN d
¡ ) (& . ° d ONLN d
√* ä6* (3 ä'If your application installs callback r ;Ä ° d ONLN d
Í*+6ó )°outines with nonstandar W¿ ° d ONLN d *ó6˙ )ld calling conventions, ° d ONLN d 7 äC ∞ (@ ähowever å† ° d ONLN d 7 ∞C )&, you might need to r Ù‡ ° d ONLN d 47 C )\6ead the chapter “Mixed Mode Manager” in this book. In ° d ONLN d jD äP· (M äOaddition, if your application explicitly loads external code modules (such as fi Ö¿ ° d ONLN d ∫D·P (M·le trans ˚ ° d ONLN d ¬DP ) - ° d ONLN d ƒQ ä] ‰ (Z älators or custom defi j` ° d ONLN d ŸQ Â] )[ nition pr ‹‡ ° d ONLN d ‚Q ]) )&ocedur t ° d ONLN d ËQ*]í ) es), you might need to r 6‡ ° d ONLN d Qì]¯ )iead the chapter “Code ° d ONLN d ^ äj (g äQFragment Manager” in this book. Read the chapter “Exception Manager” if you want ° d ONLN d gk äwÍ *
Ryour native application to handle any exceptions that arise while it is executing. ° d ONLN d ∫} äâ ê *T µ¿ ° d ONLN d ª} èâ ‹ )o use this chapter w ° d ONLN d Õ} ‹â! )M, you should alr ø` ° d ONLN d ›}!âÓ )E.eady be generally familiar with the Macintosh ° d ONLN d
ä äñ (ì ä Operating System. See the books ÄÄ ° d ONLN d
+ä ñq )ìInside Macintosh: Pr 4@ ° d ONLN d
?ärñç )Uocesses (Ä ° d ONLN d
Fäéñ£ ) and † ° d ONLN d
Kä§ñ )Inside Macintosh: Memory f† ° d ONLN d
cäñ )m ° d ONLN d
dó ä£ († äfor information about the r ˙ ° d ONLN d
ó £< )v
un-time envir ]` ° d ONLN d
åó=£ )=*onment of 680x0-based Macintosh computers. ˇ " @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-4
)B'Overview of the PowerPC System Software 4 ^ *¿¯
° d ONLN d \ l hh ( e l9This chapter begins with a description of the mixed envir ≈@ ° d ONLN d 9 \h hñ )¸ onment pr † ° d ONLN d B \ó h÷ )/ovided by the ° d ONLN d P i l u € ( r lPowerPC system softwar ć ° d ONLN d f i € u— )o7e. Then it gives information about the native PowerPC r ¿ ° d ONLN d ù i“ u˜ )˜un-time ° d ONLN d • v l Ç É ( lenvir n† ° d ONLN d ™ v É Ç÷ )Ionment. This chapter ends by explaining how to perform a number of specifi ˆ† ° d ONLN d Ù v÷ Ç‹ ( ÷c ° d ONLN d ˜ É l è „ ( å ltasks in the PowerPC envir @ ° d ONLN d É ‰ èö )x'onment, such as patching system softwar ‹ ° d ONLN d8 Éô è∂ )µe traps ô‡ ° d ONLN d? É∑ èπ ) .
[ ( *&Overview of the PowerPC System Softwar æ\ ° d ONLN dc ˜[
b ([e ˇˇˇˇˇˇ V˛ )ï1
° d ONLN df l' ¬ ($ lThe system softwar ↠° d ONLN dx ¬' )Ve for PowerPC pr ` ° d ONLN dà'/ )Mocessor m@ ° d ONLN dè/'Ó ) *-based Macintosh computers is System 7.1, ° d ONLN dπ( l4* (1 l*with suitable changes made to support the ‡ ° d ONLN d„(*4É )æmixed environment ô† ° d ONLN dÙ(Ñ4Î )Z that allows both 680x0 ° d ONLN d 5 lA ç (> lsoftwar ‰¿ ° d ONLN d5 çA ı )!e and PowerPC softwar 3@ ° d ONLN d(5 ˆAl )ie to execute on a computer ø ° d ONLN dB5kA∏ )u. The mixed envir 3‡ ° d ONLN dS5πA› )Nonment ° d ONLN dZB lN u (K lpr G ° d ONLN d\B vNò )
Bovides virtually complete compatibility for existing 680x0 softwar w@ ° d ONLN dûBòNÎ (Kòe, as well as vastly ° d ONLN d≥O l[ } (X lincr o ° d ONLN d∑O }[i )4eased performance for applications and other softwar ˚‡ ° d ONLN dÎOi[ç )Ï e that ar ‡† ° d ONLN dÙOç[ˆ )$e built to use the native ° d ONLN d\ lh Ä (e linstr ó¿ ° d ONLN d\ Äh ) uction set of the PowerPC micr ï ° d ONLN d1\ h )âopr —¿ ° d ONLN d4\h8 )ocessor •‡ ° d ONLN d;\8h: ) . ° d ONLN d=n lz  (w lBecause the system softwar é† ° d ONLN dWn Âz1 )ye for PowerPC pr ` ° d ONLN dgn2zR )Mocessor r@ ° d ONLN dnnRz› ) -based Macintosh computers is ° d ONLN då{ lá ò (Ñ l
derived fr d‡ ° d ONLN dñ{ òá⁄ ),Dom System 7.1 for 680x0-based Macintosh computers, your application— ° d ONLN d⁄à lîg (ë l4whether 680x0 or PowerPC—must conform to the basic r û‡ ° d ONLN dàgî~ )˚equir ∂ ° d ONLN dà~î÷ )ements imposed by ° d ONLN d%ï l° Æ (û lsystem softwar M‡ ° d ONLN d3ï Ø° )Ce versions 7.0 and later ∫ ° d ONLN dKï°O )d. In particular ` ° d ONLN dZïO°Í )<$, your application (or other softwar 9‡ ° d ONLN d~ïÍ°Ù )õe) ° d ONLN dÅ¢ lÆ è (´ lmust be
° d ONLN dâ∏ lø q *n
° d ONLN dãµ x¡ ™ ) 32-bit clean
° d ONLN dò l— q (– ln
° d ONLN dö« x”' ) 'compatible with the operations of the V Ä ° d ONLN d¡«'”ë )Øirtual Memory Manager
° d ONLN d◊‹ l„ q (‚ ln
° d ONLN dŸŸ xÂã ) >able to operate smoothly in the cooperative multitasking envir ∏@ ° d ONLN dŸãÂÒ (‚ãonment maintained by ° d ONLN d, xÒ í (Ó xthe Pr ¨ ° d ONLN d2 íÒ ” )
ocess Manager ° d ONLN d@ˆ l † (ˇ l If your 680x Y` ° d ONLN dLˆ ° )5 0 softwar > ° d ONLN dUˆ ’ ))e c ¯ ° d ONLN dXˆ ’= ) onforms to these specifi ï‡ ° d ONLN dpˆ>H )ic r K ° d ONLN dsˆI` ) equir b` ° d ONLN dxˆ`‘ )ements and to the general ° d ONLN dí l o ( lr E ° d ONLN dì p á )equir \@ ° d ONLN dò á · )ements for Macintos d` ° d ONLN d´ ·
)Z h softwar Ä ° d ONLN d¥ )*e d ‡ ° d ONLN d∑Y )
ocumented thr \@ ° d ONLN dƒYÅ )Aoughout x` ° d ONLN dÃÅΔ )(Inside Macintosh Z` ° d ONLN d‹«fi )F, it is ° d ONLN d‰ l ï ( l highly pr X‡ ° d ONLN dÌ ï 8 ))&obable that it will execute without pr 9 ° d ONLN d8 û )£oblems on PowerPC pr :@ ° d ONLN d'û æ )focessor û ° d ONLN d.æ › ) -based ° d ONLN d5 l)h (& l7Macintosh computers. This is because the system softwar Ä ° d ONLN dl i)µ )˝e for PowerPC pr õ@ ° d ONLN d| µ)’ )Locessor ˇ ° d ONLN dÉ ’)Ù ) -based ° d ONLN dä* l6 Ø (3 l
Macintosh com @ ° d ONLN dó* ∞6 º )Dpu (Ä ° d ONLN dô* º6 ) ters includes a very ef ÅÄ ° d ONLN d∞* 6" )`fi é@ ° d ONLN d≤*"6ú )cient 68LC040 Emulator tha Ä ° d ONLN dÃ*ù6“ ){ t emulates 6 - ° d ONLN dÿ*“6Ë )580x0 ° d ONLN d›7 lC Ä (@ linstr ó¿ ° d ONLN d‚7 ÄC õ )uction Ä¿ ° d ONLN dË7 úC ø ) s with P Ä ° d ONLN d7 ¿C ˙ )$ owerPC instr [† ° d ONLN d¸7 ˙C® ):(uctions. In addition, the system softwar Ó@ ° d ONLN d$7®CÁ )Æe includes the ° d ONLN d3D lP Œ (M lMixed Mode Manager ê` ° d ONLN dED ŒP ˛ )b , which is r Õ ° d ONLN dQD ˛PÌ )04esponsible for handling any necessary mode switches ° d ONLN dÖQ l] (Z l between the native PowerPC envir ∫@ ° d ONLN d•Q]Ä )ôonment and the 680x0 envir î@ ° d ONLN døQÄ]° ){onment åÄ ° d ONLN d≈Q¢]§ )". ° d ONLN d«c lo Ñ (l lFigur R¿ ° d ONLN dÃc Ño ò )e 1-1 @ ° d ONLN d—c òon )/ shows a general overview of the system softwar R¿ ° d ONLN d cooª )◊e for PowerPC pr “Ä ° d ONLN d cªo€ )Locessor 6` ° d ONLN d c‹ofl )!- ° d ONLN d p l| Ë (y lbased Macintosh computers é ° d ONLN d 2p Ë| Ì )|. /¿ ° d ONLN d 4p Ì| Ù )A j` ° d ONLN d 5p Ù|^ ) small kernel, called the † ° d ONLN d Op_|ï )k nanokernel, ‘@ ° d ONLN d Zpï|⁄ )6 communicates ° d ONLN d h} lâ x (Ü ldir I ° d ONLN d k} yâ Ì )
ectly with the PowerPC pr ÁÄ ° d ONLN d Ñ} Ìâ- )tocessor and pr -@ ° d ONLN d í}.†)A(ovides very low-level services (such as ° d ONLN d ∫ä lñ Ñ (ì linterr ° d ONLN d ¿ä Öñ< )$upt handling and memory management). ˇ" @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ ä'Overview of the PowerPC System Software
Figure 1-1 ° d ONLN d \ Ã gÚ )BCThe system software for PowerPC processor-based Macintosh computers
° d ONLN d PÒ ä˝ (˙ ä Even applications written entir -` ° d ONLN d oÒ˝ )â7ely in 680x0 code might cause mode switches while they ° d ONLN d ¶˛ ä
í ( äar E ° d ONLN d ®˛ ì
˛ ) Oe executing, because some portions of the Macintosh Operating System have been ° d ONLN d ˜ ä ç ( är E ° d ONLN d ¯ é$ )!ewritten in PowerPC code for incr √@ ° d ONLN d $Ò )ñ+eased performance. For example, the Memory ° d ONLN dD ä$ ‡ (! äManager has been r Q† ° d ONLN dV ·$4 )Wewritten in C and r Ô‡ ° d ONLN di4$ )S)ecompiled into PowerPC code. In general, ° d ONLN dí% ä1 ∞ (. ähowever å† ° d ONLN dô% ∞1l )&), mode switches occur completely transpar ° d ONLN d¬%m1Œ )Ωently to 680x0 softwar (@ ° d ONLN dÿ%Œ1 )ae. Only native ° d ONLN dÁ2 ä> ◊ (; äPowerPC softwar ¿ ° d ONLN dˆ2 ÿ>ò )N*e needs to worry about mode switches. See g ° d ONLN d 2ò> )¿“Mixed Mode” beginning ° d ONLN d7? äK Ø (H äon page !¿ ° d ONLN d?? ∞K ¬ )&1-13 u† ° d ONLN dC? ¬K Û )
for details. ° d ONLN dQQ ä]C (Z ä(As you would expect, the emulation envir # ° d ONLN dyQD]r )∫ onment pr bÄ ° d ONLN dÇQr] ). ovided by the 68LC040 Emulator ° d ONLN d°^ äj — (g äuses the standar Ÿ† ° d ONLN d±^ —j ˘ )G d 680x0 r ¸† ° d ONLN d∫^ ˘j\ )(un-time model. The or ˛‡ ° d ONLN dœ^\j )c'ganization of an application partition ° d ONLN dˆk äw ± (t ä and the r ) ° d ONLN dˇk ≤wZ )($un-time behavior of emulated softwar @ ° d ONLN d#kZwj )®e ar (‡ ° d ONLN d'kjw— )e identical to what is pr § ° d ONLN d@k—w )g
° d ONLN d¡Ö:ëQ ) ent fr Ä` ° d ONLN d«ÖQëì )om the standar ÿ¿ ° d ONLN d’Öìëª )B d 680x0 r ˚¿ ° d ONLN dfiÖªë˜ )(
un-time envir _ ° d ONLN dÎÖ¯ë )=on- ° d ONLN dÔí äû ¸ (õ äment. The PowerPC envir é¿ ° d ONLN dí ¸û* )r onment pr Œ ° d ONLN dí*ûΩ ). ovides a much simpler and easier ú@ ° d ONLN d/íæû‚ )î -to-use r h@ ° d ONLN d8í„û )%un-time ° d ONLN d@ü ä´ (® ämodel based on fragments. m¿ ° d ONLN dZü´ )zA ®` ° d ONLN d[ü ´
) (` ° d ONLN d\ü´7 )fragment “ ° d ONLN ddü7´ ))1 is any block of executable PowerPC code and its ° d ONLN dï¨ ä∏ (µ ä associated data. Fragments ar @ ° d ONLN d≤¨
∏ )Ée cr ë ° d ONLN d∂¨ ∏⁄ ))eated by your development system’s linker õ¿ ° d ONLN dfl¨⁄∏‹ )æ.
ˇˇ ˇ ˛ˇˇ ˛ˇ ˛ˇÅ Å Ú ü ˇ… ˇÈ ˇ— ˇÅ Å Ô ü ˇ ˇË ˇ— ˇÅ Å Ô † ˇˇ˛≤ ˛ˇˇ” ˛ˇÅ Å Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â òů Ä ú˜ H H gû¨ 5ÕÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä ú˜. áJ~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Í ˇˇÛ ˇˇı ˛ˇ ˇ— ˛ˇÅ Å Å ˆ Í ˇˇÚ ˇˆ ˇ˛ ˇœ ˇÅ Å Å ı "Î ˇ ˇÚ ˇ˜ ˇ˝ ˇ‰ ˇÌ ˇÅ Å Å ı WÏ ˇ ˇ ˝ˇ ˝ˇ˛ ˇ˛ ˇˇ˚ ˇ˘ ˇˇ ˇ ˇˇ ˇˇ ˝ˇ ˇˇ ˇ ˝ˇ ˇˇ ˇ ˇˇ¯ ˇˇ ˇˇ˝ ˇˇÅ Å Å ˛ ]Ï ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ˝ ˇ˘ ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ˛ ˇ ˇ ˇˆ
˛êêê @˜J áä~ ' Ï ¸ˇ ˇˇ‘ ˇˇ˚ ˛ˇÅ Å Å fi !Î ˇ ˇ ˇ’ ˇ ˇ˝ ˇ˛ ˇÅ Å Å fl "Î ˇ ˛ ˇÙ ˇÙ ˇÓ ˇ˘ ˛Å Å Å fl >Ï ˇ ˇ ˇ ˇˇ ˇ ˛ˇ ˝ˇ ˇˇ˛ ˇˇ ¸ˇ ˇˇ ˇ ˇˇ˘ ˇ˘ ˇÅ Å Å fi ?Ï ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ ˇ˝ ˇ ˇ ˇ ˇ ˇ ˇ˘ ˇˇ˘ ˇÅ Å Å › >Ï ˇ ˇ ˛ ˇ ˇ ˇ˝ ˇ ˇ˛ ˇ˛ ˇ ˛ ˇ˛ ˇ ˇ˜ ˛˚ ˇÅ Å Å ‹ =Ì ˇ ˇ ˇ ˇ ˇ˝ ˇ ˇ ˇ˝ ˇ ˇ ˇ ˇ˛ ˇ ˇˆ ˇ¸ ˇÅ Å Å € EÌ ˇ ˇ ˇˇ ˇˇ ˇ ˇˇ ˇ ˇ ˇˇ˝ ˇ ˇ ˇˇ ˇˇ ˇ ˇ˙ ˇ ˇ¸ ˇ˝ ˇÅ Å Å fl EÓ ˇˇ˛ ˇ ˇ ˇˇ ˛ ˇˇ˛˛ ˛ ˇ¸
˛ˇ ˇ ˇ ˇˇ˛ ˇ˘ ˇ˛˛ ˛ ˇ˛˛ˇÅ Å Å fi Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â òů @ Ę H H gû¨ 5œÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ęä á ~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â òů Ä ú˜ H H gû® 5–Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä ú˜ áÊ~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â ò @ @˜ @˜Ê á&~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ę @ Ę& áf~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä ú˜ Ä ú˜f áÇ~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òů @˜ H H gû¨ 5—Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @˜Ê á&~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â òů @ Ę H H gû® 5“Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ę& áf~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â òů Ä ú˜ H H gû¨ 5”Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä ú˜f áÇ~ ' Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â Å Å Å â ˇ!~ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-6
)BThe 68LC040 Emulator 4 ^ *¿¯
^ * k¯ 4 ^ * k¯ ° d ONLN d ] l h ( e lNote
ˇ·ˇ‚7^
° d ONLN d
i l u ñ *
The term ` ° d ONLN d i ó u ª )+fragment ∑` ° d ONLN d i ª u¶ )$7 is not intended to suggest that the block of code and ° d ONLN d R u l Å™ ( ~ lHdata is in any way either small, detached, or incomplete. Fragments can ° d ONLN d ö Å l ç * %be of virtually any size, and they ar 3` ° d ONLN d ø Å ç¶ )ú%e complete, executable entities. The ° d ONLN d ‰ ç l ô É ( ñ lterm “† ° d ONLN d È ç É ô ß )fragment {† ° d ONLN d Ò ç ® ôÉ )%1 was chosen to avoid confusion with the terms alr b` ° d ONLN d" çÉ ôö )€eady ° d ONLN d' ô l • é ( ¢ lused in c@ ° d ONLN d/ ô è • ‘ )#Inside Macintosh E@ ° d ONLN d? ô ’ •x )F& to describe executable code (such as Õ ° d ONLN de ôx •§ )£ component ‹` ° d ONLN dn ô§ •¶ ), ° d ONLN do • l ± ( Æ land Ì ° d ONLN ds • ± ú )module ^† ° d ONLN dy • ù ± ¢ ) ). ,
Zapf Dingbats
2Ä ° d ONLN d| ® ® ∞ Æ ) u
° d ONLN d~ ∂ l ¬ ˚ ( ø l Fragments use a method of addr Ä ° d ONLN dú ∂ ¸ ¬£ )ê(essing the data they contain that is dif # ° d ONLN dƒ ∂£ ¬Ø )ßfer † ° d ONLN d« ∂Ø ¬Â ) ent and mor fi† ° d ONLN d“ ∂‰ ¬Î )5e ° d ONLN d‘ √ l œ ∂ ( à lgeneral than the 2‡ ° d ONLN d √ ∂ œ )JA5-r ° d ONLN dÈ √ œ® )2elative method that 680x0 applications use to addr W ° d ONLN d √® œÏ )fiess their global ° d ONLN d, – l ‹Å ( Ÿ l;data. One important consequence is that any PowerPC softwar x` ° d ONLN dg –Å ‹Û ( ŸÅe packaged as a fragment ° d ONLN dÄ › l Èä ( Ê lAhas easy access to global data. In the 680x0-based system softwar º‡ ° d ONLN d¡ ›ä È‚ ( Êäe, it was sometimes ° d ONLN d’ Í l ˆ x ( Û ldif ™` ° d ONLN dÿ Í x ˆ ~ ) fi ∑ ° d ONLN d⁄ Í ~ ˆH )/cult to use global data within types of softwar Ô@ ° d ONLN d ÍH ˆ∑ ) e other than applications. ° d ONLN d$ ¸ l+ ( l-In addition, it was often complicated for a r ÃÄ ° d ONLN dQ ¸+w )øoutine installed b Ö¿ ° d ONLN dc ¸x¥ )M
y some code t ÚÄ ° d ONLN dp ¸¥— )<o gain ° d ONLN dx l ù ( l access to th o¿ ° d ONLN dÑ û º )2e code’ K¿ ° d ONLN dã Ω≥ ) 7s global variables. For example, you cannot—in the curr Ï ° d ONLN d¬ ≥fl )ˆ
ent 680x0 ° d ONLN dà l" É ( lenvir n† ° d ONLN d— É" „ )onment—write a VBL ∂ ° d ONLN d„ „"‰ )`< task that uses your application’s global variables without ° d ONLN d # l/ (, l#somehow passing your application’s é ° d ONLN dB#/i )§A5 value to the VBL [@ ° d ONLN dU#i/Ç )Y task. È¿ ° d ONLN d\#Ç/ç )(A x@ ° d ONLN d^#ç/è ) ¯@ ° d ONLN d_#è/£ )VBL Y ° d ONLN db#§/π ) task π ° d ONLN dg#π/ı ) is a task that ° d ONLN dw0 l<" (9 l*executes during a vertical blanking interr p‡ ° d ONLN d°0"<9 )∂upt.) ` ° d ONLN dß0:<ô )In the PowerPC envir ?@ ° d ONLN dª0ô<÷ )_
Courier =` ° d ONLN dÉ™ „∂ ) UnloadSeg =` ° d ONLN då™∂% )6 pr ¿ ° d ONLN dè™%∂B ) ocedur ‚ ° d ONLN dï™A∂R ) e ar ¥Ä ° d ONLN dô™R∂í )e simply ignor ܇ ° d ONLN dß™í∂È )@ed by the PowerPC . ° d ONLN dπ∑ l√ Æ (¿ lsystem softwar M‡ ° d ONLN d«∑ Ø√ )Ce. The task of keeping r ›Ä ° d ONLN dfl∑√, )fequir Ù¿ ° d ONLN d‰∑,√0 )e æ` ° d ONLN dÂ∑1√> )d c ` ° d ONLN dË∑>√ı )
'ode in memory is handled completely by ° d ONLN dƒ l– É (Õ lthe V à‡ ° d ONLN dƒ É– ) irtual Memory Manager or the Pr Δ ° d ONLN d3ƒ–W )ì
ocess Manager D ° d ONLN d@ƒW–Δ )A, not by your application. ° d ONLN d[÷ l‚ É (fl lThe r Ä¿ ° d ONLN d`÷ É‚R )0emaining sections in this chapter describe in gr »Ä ° d ONLN dê÷R‚À )œ eater detail the mixed envir † ° d ONLN d¨÷ )zonment ° d ONLN d≥„ lÔ ≠ (Ï l
of PowerPC pr √Ä ° d ONLN d¿„ ≠Ô Õ )Aocessor '` ° d ONLN d«„ ŒÔ™ )!/-based Macintosh computers and the new native r Ä ° d ONLN dˆ„´Ô– )›un-time ° d ONLN d˛ l¸ É (˘ lenvir n† ° d ONLN d ɸ )onment. If you’r 1@ ° d ONLN d À¸ Á )He inter † ° d ONLN d Á¸1 ) ested mainly in r 8 ° d ONLN d +1¸” )J%ebuilding your application as native ° d ONLN d P˝ l ) ( l*PowerPC code, you can skip to the section ˇ‡ ° d ONLN d z˝) √ )Ω “Mixed Mode” beginning on page ¿ ° d ONLN d ô˝ƒ ÷ )õ1-13 e† ° d ONLN d ù˝÷ € ), ° d ONLN d ü
l„ ( lOwhich describes the ways in which you might need to use the Mixed Mode Manager ° d ONLN d Ô l#ã *
?to make your native application compatible with the mixed envir † ° d ONLN d
af “ré )S* is the part of the PowerPC system softwar ¶¿ ° d ONLN d
ãfér‰ )ºe that allows 680x0 ° d ONLN d
üs l Û (| l applications and other softwar ã@ ° d ONLN d
Ωs Ûm )áe to execute on PowerPC pr ç ° d ONLN d
◊smç )zocessor ‡ ° d ONLN d
fisç› ) -based Macintosh ° d ONLN d
ÔÄ lå Í (â lcomputers. This emulator pr î‡ ° d ONLN d
Ä Íå[ )~ovides an execution envir †@ ° d ONLN d #Ä[åÓ )q#onment that is virtually identical ° d ONLN d Fç lô À (ñ lto the execution envir (¿ ° d ONLN d \ç Ãô )`<onment found on 680x0-based Macintosh computers. The emulato ∞‡ ° d ONLN d òçôˆ (ñr ° d ONLN d öö l¶ ô (£ l
converts 6 ô ° d ONLN d §ö ô¶ √ )-
80x0 instr Y` ° d ONLN d Æö ƒ¶: )+uctions into PowerPC instr ;¿ ° d ONLN d »ö;¶´ )wuctions, issues those instr yÄ ° d ONLN d „ö´¶È )puctions to the ° d ONLN d Úß l≥ ¨ (∞ l PowerPC micr §† ° d ONLN d ˛ß ¨≥ ª )@opr ·@ ° d ONLN d ß ª≥ € )ocessor µ` ° d ONLN d ß €≥m ) , and updates the emulated envir ë` ° d ONLN d (ßm≥Ù )í onment (such as the emulated ° d ONLN d E¥ l¿ ã (Ω l680x0 r ̆ ° d ONLN d L¥ ã¿ ¡ ) egisters) in r z ° d ONLN d Z¥ ¬¿ê )7-esponse to the operations of the PowerPC micr ` ° d ONLN d á¥ë¿† )œopr P ° d ONLN d 䥆¿¿ )ocessor $ ° d ONLN d 륿¿¬ ) . ˇ"Æ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ äThe 68LC040 Emulator
Unless you ar ` ° d ONLN d» √ « œ ÿ )=e pr & ° d ONLN dà √ ÿ œØ )-ogramming in assembly language or doing very ° d ONLN d˘ œ ä € ( ÿ älow-level debugging, you’r Ü@ ° d ONLN d œ €´ )x(e not likely to need the information in ° d ONLN d< € ä Á ( ‰ äthe following two sections. ,
° d ONLN dn ä m ( ä/The 68LC040 Emulator implements the basic Motor π` ° d ONLN dùm › )„ola 68040 user mode instr ^@ ° d ONLN d∂fi
)q uction set. ° d ONLN d¬ ä+ ‰ (( äIt does not, however N† ° d ONLN d÷ ‰+Q )Z, support any of the instr `Ä ° d ONLN d Q+z )m
uctions fr ` ° d ONLN d˙ {+ )* om the optional 68881 or 68882 ° d ONLN d, ä8 ê (5 äfl å¿ ° d ONLN d, ê8 › )oating-point copr Ç ° d ONLN d,, ›8 )M
ocessors. Mor @ ° d ONLN d9,82 )=eover ‰Ä ° d ONLN d>,18 )3, although the emulator supports the operations of ° d ONLN dq9 äE ° (B äthe V à‡ ° d ONLN dv9 °E )irtual Memory Manager tÄ ° d ONLN dã9 Ez )j, it does not support instr À ° d ONLN d¶9zE£ )o
uctions fr ⇠° d ONLN d∞9§E˛ )*om the 68851 Paged ° d ONLN d√F äR˚ (O äHMemory Management Unit (PMMU). The 680x0-based Macintosh computer whose ° d ONLN d S ä_ ò *
har ` ° d ONLN dS ô_ ∞ )dwar N ° d ONLN dS ∞_ Õ )e confi [† ° d ONLN dS Õ_2 ) guration most closely r ∞@ ° d ONLN d0S2_é )eesembles the softwar
@ ° d ONLN dDSè_¨ )]e confi ¿ ° d ONLN dKS¨_ ) guration of the ° d ONLN d[` äl— (i äG68LC040 Emulator is the Macintosh Centris 610, which contains the Motor ∏¿ ° d ONLN d¢`—l (i— ola 68LC040 ° d ONLN dÆm äy û (v ämicr q† ° d ONLN d≤m ûy ≠ )opr Æ@ ° d ONLN dµm ≠y Õ )ocessor Ç` ° d ONLN dºm Õy% ) . (The 68LC040 micr ∂` ° d ONLN dœm%y4 )Xopr Û ° d ONLN d“m4y‘ )&ocessor is identical to the 68040 micr S@ ° d ONLN d¯m’y‰ )°opr è‡ ° d ONLN d˚m‰y )ocessor ° d ONLN dz äÜ Í (É äexcept that it has no fl SÄ ° d ONLN dz ÎÜ3 )aoating-point uni \¿ ° d ONLN d+z3Ü8 )Ht. ° d ONLN d-z9Ü> )) î† ° d ONLN d/z>ÜW )As a r ]‡ ° d ONLN d5zXÜ
)+esult, if your application or other softwar @ ° d ONLN d`zÜ )∂e ° d ONLN dbá äì ç (ê är ^† ° d ONLN dcá éì – )uns without pr M` ° d ONLN dqá –ì )B;oblems on the Macintosh Centris 610, it is very likely to r ‡ ° d ONLN d¨áÀì˛ )˚ un without ° d ONLN d∑î ä† ì (ù äpr G ° d ONLN dπî î†6 )
!oblems under the 68LC040 Emulator î@ ° d ONLN d⁄î5†7 )°.
Æ Hº 4Ø Hº
° d ONLN d‹≠ ä∏ ù (µ äNote
ˇ·ˇ‚7^
° d ONLN d·∫ äΔ Û *For the complete specifi º† ° d ONLN d˘∫ ÛΔî )i$cation of how you can expect both a ° d ONLN d Δ ä“ ç (œ är E ° d ONLN d Δ é“Å )6eal 68040 and the 68LC040 Emulator to behave, see the ° d ONLN dV“ äfi  (€ äMC68040 32-Bit Micr %‡ ° d ONLN di“ Êfi Û )\opr L ° d ONLN dl“ Ûfi% )
ocessor User Ä ° d ONLN dx“&fi( )3’ X ° d ONLN dy“(fiN )s Manual Ú ° d ONLN dÅ“NfiP )&.
r ° d ONLN dÉ’V›\ )u
. ° d ONLN dÖ„ äÔ û (Ï äThe ,
Courier ° d ONLN dâ„ ûÔ » )Gestalt ° d ONLN dê„ »Ô Ù )* function r R` ° d ONLN dõ„ ÙÔ? ),eturns the value R` ° d ONLN d¨„?Ôá )K gestalt68020 R` ° d ONLN d∏„áÔ
)H when you pass it the selector ° d ONLN d◊ ä¸ (˘ ägestaltProcessorType ° d ONLN dθn )x and the calling softwar R` ° d ONLN dn¸— )le is executing under th R` ° d ONLN d—¸Â )ce em R` ° d ONLN d ¸ )ulator ï ° d ONLN d$ ¸ ). . ° d ONLN d&˝ ä £ ( äThis r ‹Ä ° d ONLN d,˝ £
)Peturn value is intended to highlight the two ways in which the 68LC040 Emulator ° d ONLN d|
° d ONLN dø ñ) Ï ) The emulated envir fl@ ° d ONLN d— Ï) )V?onment does not support either the FPU or the MMU contained in ° d ONLN d) ñ5 Â (2 ñan actual 68040 pr :† ° d ONLN d") Ê5 )Pocessor ¿ ° d ONLN d))5 ) .
° d ONLN d+> äE è (D än
° d ONLN d-; ñG Ï ) The emulated envir fl@ ° d ONLN d?; ÏG )V onment cr å¿ ° d ONLN dH;G∫ )-%eates exception stack frames in accor 3‡ ° d ONLN dm;ªG˛ )¢dance with the ° d ONLN d|G ñS (P ñ 68020 exception frame model. ° d ONLN dôX äd (a äVThe 68LC040 Emulator consists of two main parts, a main dispatch table and a block of ° d ONLN dÔe äqˇ *
Vadditional code called by entries in the main dispatch table. The main dispatch table ° d ONLN d Er ä~# *
!contains two native PowerPC instr µ‡ ° d ONLN d fr#~o )ôuctions for each r Ë ° d ONLN d xro~
)L#ecognized 680x0 operation code (or ° d ONLN d õ äã Ó (à äopcode). In cases wher ±` ° d ONLN d ± ÓãÛ )d9e a 680x0 opcode can be handled by a single PowerPC instr û‡ ° d ONLN d ÍÛã (àÛuction, ° d ONLN d Úå äò † (ï äthe fi Í ° d ONLN d ¯å †ò ‡ )rst native instr fl‡ ° d ONLN d
å ‡ò“ )@8uction in the dispatch table is enough to complete the r ‡ ° d ONLN d
@å”ò˝ )Û equested ° d ONLN d
Iô ä• (¢ ä!operation. In most cases, however fi¿ ° d ONLN d
jô •≥ )ï", the handling of a 680x0 opcode r •† ° d ONLN d
åô¥•À )ïequir º‡ ° d ONLN d
ëôÀ•Ë )es mor R ° d ONLN d
óôÈ• ) e than ° d ONLN d
û¶ ä≤ ‹ (Ø äone PowerPC instr [@ ° d ONLN d
ض ›≤K )Suction. In that case, the fi ´@ ° d ONLN d
À¶K≤ã )nrst native instr ° ° d ONLN d
€¶ã≤ )@ uction in the main dispatch ° d ONLN d
˜≥ äø, (º ä$table simply begins the emulation pr i` ° d ONLN d ≥,øE )¢ocess. ˇ b @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-8
)BThe 68LC040 Emulator 4 ^ *¿¯
° d ONLN d \ l h “ ( e lThe second native instr ° d ONLN d \ ” h )g uction in th œÄ ° d ONLN d # \ h )2e em ∂¿ ° d ONLN d ' \ h4 )ulator ° d ONLN d - \6 hÕ ) $’s main dispatch table is usually a ° d ONLN d Q i l u Ä ( r lPC-r πÄ ° d ONLN d U i Ä u‹ )Pelative branch into the block of additional code. The additional code continues ° d ONLN d ¶ v l ÇH ( l0the emulation of the 680x0 opcode begun by the fi ® ° d ONLN d ◊ vH Çj )‹ rst instr ±¿ ° d ONLN d ‡ vj Çà )"uction. ° d ONLN d Ë à l î w ( ë lTh r ° d ONLN d Í à x î å ) e em Y` ° d ONLN d Ó à ç î ß )ulator ∞¿ ° d ONLN d Ù à ® îÈ )J’s main dispatch table also includes entries that support private opcodes ° d ONLN d> ï l ° o ( û lr E ° d ONLN d? ï p ° )%eserved for use by the system softwar ü@ ° d ONLN dd ï °c )¶e, including both ôÄ ° d ONLN dv ïc °ƒ )MA-line and F-line instr Ù ° d ONLN dç ïƒ °È )a uctions. ° d ONLN dñ ¢ l Æ q ( ´ lF ° d ONLN dó ¢ r ÆÔ )Nor example, the Mixed Mode Manager communicates with the 68LC040 Emulator usin èÄ ° d ONLN d ¢Ô Ƙ ( ´Ôg ° d ONLN dÁ Ø l ª û ( ∏ l A-line instr û† ° d ONLN dÛ Ø û ª ≈ )2 uctions e @ ° d ONLN d¸ Ø Δ ª )( mbedded in r œ ° d ONLN d Ø ªj );outine descriptors. (See è† ° d ONLN d! Øk ªœ )j“Routine Descriptors” ° d ONLN d7 º l » ¿ ( ≈ lbeginning on page V ° d ONLN dI º ¡ » ” )U1-15 ™ ° d ONLN dM º ” »i )# for details.) Other system softwar È ° d ONLN dp ºi »‹ )ñe services, including the V 8Ä ° d ONLN dã º› »˜ )tirtual ° d ONLN dí … l ’ º ( “ lMemory Manager fi¿ ° d ONLN d† … ª ’ )O, also issue r q¿ ° d ONLN dÆ … Ò ’X )6eserved opcodes to the ’@ ° d ONLN d≈ …X ’\ )ge û‡ ° d ONLN dΔ …] ’Ä )mulator OÄ ° d ONLN dÕ …Ä ’Ç )#. ° d ONLN dœ € l Á í ( ‰ lWhen th Ä ° d ONLN d÷ € í Á ¶ )&e em g` ° d ONLN d⁄ € ß Á< )%ulator is active, it maps all 680x0 r -‡ ° d ONLN dˇ €= ÁÄ )ñegisters to the r ¡‡ ° d ONLN d €Ä ÁÓ )Cegisters on the PowerPC ° d ONLN d( Ë l Ù Ä ( Ò lmicr q† ° d ONLN d, Ë Ä Ù è )opr Æ@ ° d ONLN d/ Ë è Ù Ø )ocessor Ç` ° d ONLN d6 Ë Ø Ù
) , including the 680x0 ÜÄ ° d ONLN dL Ë
Ù )^p à† ° d ONLN dM Ë Ù )r M† ° d ONLN dN Ë Ù6 )ogram ò‡ ° d ONLN dT Ë6 Ù: ) c ° d ONLN dU Ë; ÙÛ )*ounter (PC) and Status Register (SR). The ° d ONLN d ı l ª ( ˛ lgeneral-purpose r a¿ ° d ONLN dê ı ªÕ )O>egister GPR1 serves as both the 680x0 and native stack pointer {¿ ° d ONLN dŒ ıÕ ( ˛Õ. The ° d ONLN d‘ l p ( le I† ° d ONLN d’ q )!mulator also dedicates a native r ¶@ ° d ONLN dˆ ` )èegister to point to the c‡ ° d ONLN daª )a680x0 context block, 1Ä ° d ONLN d"º‡ )[ a block ° d ONLN d, lG ( l2of data containing information that needs to be pr B¿ ° d ONLN d^Hz )‹ eserved acr FÄ ° d ONLN diz‰ )2oss mode switches. The ° d ONLN dÄ l(
(% l&context block contains all the 680x0 r ° d ONLN d¶ (Z )¢egisters, the addr 2† ° d ONLN d∏ Z(Á )L!esses of the main dispatch table ° d ONLN dŸ) l5Δ (2 lOand the block of additional code, and other information used internally by the 3 ° d ONLN d()«5À (2«e ¸† ° d ONLN d))À5Ó )mulator ≠@ ° d ONLN d0)Ó5Û )#. ° d ONLN d26 lB (? lThe ª¿ ° d ONLN d66 B É )e Ö` ° d ONLN d76 ÑB÷ )Omulator saves information into the context block when it is about to exit (for ° d ONLN dÜC lOõ (L lEexample, when a 680x0 application calls a piece of native code) and r è¿ ° d ONLN dÀCõO∞ (Lõestor @ ° d ONLN d–C±Oà )es the ° d ONLN d◊P l\ ™ (Y linformation fr ‘@ ° d ONLN dÂP ™\{ )>/om the block when it is subsequently activated.
j *x¯ 4k *x¯ ,
Zapf Dingbats
° d ONLN dj Xt ` (r Xs
° d ONLN dk ls u (q lW úÄ ° d ONLN dk us † ) ARNING
ˇ·ˇ‚7^
° d ONLN d v lÇ r ( lY @Ä ° d ONLN d v rÇ ∂ )ou should not r Ä ° d ONLN d.v ∂Ç )Dely on any specifi Ò ° d ONLN d@vÇï )L c information about the 68LC040 ° d ONLN d`Ç lé ï (ã lEmulator « ° d ONLN dhÇ ñé ‚ )*’s private data str ñ‡ ° d ONLN d{Ç „é ˙ )Muctur ¿ ° d ONLN dÄÇ ˚é9 )es or opcodes.
ã@ ° d ONLN dèÖ>çE )Cs
≤ *π¯ 4≥ *π¯ ¥ l¥¯
ˇ·ˇ‚7^
ˇˇ‹. ˇ◊ ° d ONLN dë£ l≤ Á (Æ lEmulator Limitations ˇˇˇˇˇˇ €r (Æ1
° d ONLN dßπ l≈ { (¬ lLar `¿ ° d ONLN d™π {≈ fl )gely because it is a pur û† ° d ONLN d¬π fl≈ )d ely softwar ƒÄ ° d ONLN dÕπ≈Å )1e implementation of a har Å` ° d ONLN dÊπÇ≈ô )rdwar π ° d ONLN dÍπô≈¥ )e micr Ù` ° d ONLN dπ¥≈√ )opr 1 ° d ONLN dÛπƒ≈‰ )ocessor ° d ONLN d˙π‰≈È ) , ° d ONLN d¸Δ l“q (œ l9the 68LC040 Emulator sometimes exhibits behavior that dif $† ° d ONLN d5Δr“å (œrfers fr
† ° d ONLN d<Δå“Ê )om that of an actual ° d ONLN dQ” lfl õ (‹ l
680x0 micr @ ° d ONLN d[” úfl ´ )0opr V‡ ° d ONLN d^” ´fl À )ocessor + ° d ONLN de” Àfl- ) . These operational dif •† ° d ONLN d|”-fl9 )bfer à ° d ONLN d”9flè ) ences can lead to pr (` ° d ONLN dì”êfl· )Woblems, ranging fr ` ° d ONLN d•”·flÒ )Qom ° d ONLN d®‡ lÏ (È l%the obvious (for example, using the fl $ ° d ONLN dŒ‡Ï- )•oating $‡ ° d ONLN d‘‡-Ï0 ) - x¿ ° d ONLN d’‡0Ï] )
point copr ` ° d ONLN dfl‡^Ïï ).
ocessor instr B† ° d ONLN dχïÏÏ )7uction set, which is ° d ONLN dÌ l˘Ï (ˆ lTnot supported by the 68LC040 Emulator) to the subtle (for example, depending upon a ° d ONLN dU˙ l º *
value in an undefi µ ° d ONLN dg˙ º√ )P=ned condition code bit). If your application or other softwar ‰ ° d ONLN d§˙√Ú (√
e depends ° d ONLN dÆ l Ò ( l on 680x0 behavior that is not r “† ° d ONLN dÕ Ò ˇ )Öepr c` ° d ONLN d– µ )&oduced exactly by the 68LC040 Emulator · ° d ONLN dˆ¥⁄ )¥ , your pr &Ä ° d ONLN dˇ€ˆ )'oduct ° d ONLN d l ™ ( l
might have pr Á† ° d ONLN d ™ j )>(oblems when executing under the emulator ±¿ ° d ONLN d :j )¿ . The known exceptions to the ° d ONLN d X! l- fi (* ldocumented 680x0 specifi ∂ ° d ONLN d p! fi-" )rcations concern
° d ONLN d Ä7 l> q (= ln
° d ONLN d Ç4 x@ ã ) copr ,‡ ° d ONLN d Ü4 å@ ⁄ )ocessors and instr @ ° d ONLN d ò4 €@ )O uction sets
° d ONLN d §I lP q (O ln
° d ONLN d ¶F xR å ) instr ó¿ ° d ONLN d ´F åR À )uction timings
° d ONLN d ∫[ lb q (a ln
° d ONLN d ºX xd Ø )
deleted instr ÷‡ ° d ONLN d …X Ød œ )7uctions
° d ONLN d —m lt q (s ln
° d ONLN d ”j xv » ) unsupported instr »Ä ° d ONLN d ‰j »v )P
uction featur ]Ä ° d ONLN d Òjv
)9es
° d ONLN d Ù lÜ q (Ö ln
° d ONLN d ˆ| xà å ) instr ó¿ ° d ONLN d ˚| åà « )
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä hw ( e ä7The following sections describe these limitations in gr ø† ° d ONLN d 7 \w h™ )Ì
eater detail.
Ü H ç 4 á H ç à ä à
ˇ·ˇ‚7^
° d ONLN d E y ä á ‘ ( É ä Coprocessors ˇˇˇˇˇˇ ‘@ ( É1
° d ONLN d S ç ä ô ¢ ( ñ äAs pr À` ° d ONLN d X ç ¢ ôœ )Ceviously indicated, the 68LC040 Emulator does not support the instr M† ° d ONLN d õ ç– ô ( ñ–uction sets of ° d ONLN d ™ ö ä ¶ ( £ ä either the 68881 or the 68882 fl 1† ° d ONLN d ö ¶] )Üoating-point copr &‡ ° d ONLN d € ö] ¶Ë )M ocessor or of the 68851 PMMU. §@ ° d ONLN d ˘ öË ¶˝ )ãAny ° d ONLN d ˝ ß ä ≥ ´ ( ∞ äsoftwar ‰¿ ° d ONLN d ß ´ ≥ · )!
e that uses fl ‹ ° d ONLN d ß ‚ ≥/ )7oating-point instr < ° d ONLN d$ ß0 ≥n )Nuctions is ther )‡ ° d ONLN d3 ßn ≥ )>efor Ň ° d ONLN d7 ß ≥Ú )e not compatible with the ° d ONLN dQ ¥ ä ¿ ‹ ( Ω ä68LC040 Emulator ˇ ° d ONLN da ¥ € ¿ )Q. Because ther ч ° d ONLN do ¥ ¿( )=e ar ìÄ ° d ONLN ds ¥( ¿ˇ )/e several 680x0-based Macintosh computers that ° d ONLN d£ ¡ ä Õ “ ( ädo not contain fl ⁄Ä ° d ONLN d¥ ¡ “ Õ )Hoating-point copr œ¿ ° d ONLN d≈ ¡ Õ_ )Mocessors, this r ` ° d ONLN d’ ¡` Õ¸ )A&estriction is not likely to cause new ° d ONLN d˚ Œ ä ⁄ — ( ◊ äcompatibility pr ¿ ° d ONLN d Œ — ⁄; )Goblems for your softwar @ ° d ONLN d" Œ< ⁄¸ )k,e. It’s possible that you have used SANE to ° d ONLN dN € ä Á ø ( ‰ ä perform har ‰¿ ° d ONLN dY € ø Á ÷ )5dwar Ä ° d ONLN d] € ◊ Á )e-independent fl ¸ ° d ONLN dm € Á» )H)oating-point arithmetic. If so, you’ll pr ;† ° d ONLN dñ €… Á )™obably notice ° d ONLN d§ Ë ä Ù £ ( Ò äthat fl b‡ ° d ONLN d´ Ë § Ù ) oating-point calculations ar W@ ° d ONLN d« Ë Ù
)y3e performed even faster under the 68LC040 Emulator ° d ONLN d˙ ı ä π ( ˛ ä than on a r Ò ° d ONLN d ı π\ )/"eal 680x0-based Macintosh computer ≥@ ° d ONLN d' ı\€ )£ . This is because PowerPC pr 9Ä ° d ONLN dC ı‹¸ )Äocessor ù` ° d ONLN dJ ı¸ˇ ) - ° d ONLN dL ä ( äSbased Macintosh computers include an accelerated version of SANE written in native ° d ONLN dü ä Õ *
PowerPC code. ° d ONLN d≠! ä-¢ *:The 68LC040 Emulator does not support the 68851 PMMU instr <¿ ° d ONLN dÁ!£- (*£uction set (which also ° d ONLN d˛. ä:y (7 ä3includes the 68030 and 68040 internal PMMUs). The V , ° d ONLN d1.y: )Ô irtual Memory Manager is still ° d ONLN dP; äG ˝ (D äsupported, but using a dif `¿ ° d ONLN dj; ˝G )sfer C@ ° d ONLN dm; GX ) ent mechanism. V g ° d ONLN d};WG» )Nery few applications addr ó@ ° d ONLN dñ;»G )q
ess the PMMU ° d ONLN d£H äT ñ (Q ädir I ° d ONLN d¶H óT ´ )
ectly ! ° d ONLN d´H ´T “ ) , so this r —¿ ° d ONLN d∂H “TF )' estriction is not likely to af Ö` ° d ONLN d‘HGT )u.fect many developers. Those applications that ° d ONLN dU äa ≠ (^ ädo addr ç¿ ° d ONLN d U ≠a ˝ )#ess the PMMU dir ≥@ ° d ONLN dU ˝a )Pectly ar Ï ° d ONLN d!U aa ) e very likely alr u† ° d ONLN d2UbaÕ )Eeady incompatible with 8‡ ° d ONLN dIUÕa )kA/UX and with ° d ONLN dWb än ° (k äthe V à‡ ° d ONLN d\b °n )irtual Memory Manager tÄ ° d ONLN dqb n
)j. ° d ONLN dst äÄ ú (} äMor /¿ ° d ONLN dvt ùÄ Õ ) e generally £‡ ° d ONLN dÅt ÃÄß )/0, the 68LC040 Emulator does not support the copr \ ° d ONLN d±t®Ä )‹ocessor bus interface. ° d ONLN d»Å äç £ (ä äAs a r I@ ° d ONLN dŒÅ §ç Œ ) esult, the fl ° d ONLN dŸÅ Œç “ )*e ®¿ ° d ONLN d⁄Å ”çΔ )5mulator does not support any externally connected har ≠‡ ° d ONLN dÅΔç› )Ûdwar † ° d ONLN dÅ›ç‰ )e ° d ONLN dé äö ù (ó äcopr ,‡ ° d ONLN dé ûö ≈ ) ocessors.
∏ Hø 4π Hø ∫ ä∫
ˇ·ˇ‚7^
° d ONLN d#´ äπ ƒ (µ ä Instruction ˆ@ ° d ONLN d/´ ƒπ À ):T ŸÄ ° d ONLN d0´ Àπ Ì )imings ˇˇˇˇˇˇ ‘@ (µ1
° d ONLN d8ø äÀI (» ä)The 68LC040 Emulator executes 680x0 instr 4‡ ° d ONLN daøJÀÒ )¿'uctions as fast as possible, making no ° d ONLN dàà äÿú (’ ä=attempt to maintain the same number of clock counts as on a r Ó` ° d ONLN d≈Ãúÿ⁄ (’úeal 68040 micr í ° d ONLN d”ÀÿÍ )?opr Œ† ° d ONLN d÷ÃÍÿ
)ocessor ¢¿ ° d ONLN d›Ã
ÿ ) . ° d ONLN dflŸ ä û (‚ äTher ¿ ° d ONLN d„Ÿ üÂ Ø )e ar ` ° d ONLN dÁŸ Ø ˆ )e classes of instr ` ° d ONLN d˘Ÿ ˆÂ˙ )G:uctions that execute in the same number of cycles whether ° d ONLN d4Ê äÚ £ (Ô äon a r ㇠° d ONLN d:Ê £ÚY )'eal 68040 or under the 68LC040 Emulator 3 ° d ONLN daÊYÚ¸ )∂%, but you should not depend on this. ° d ONLN dáÛ äˇò (¸ ä@In general, of course, your 680x0 application is most likely alr H† ° d ONLN d«Ûôˇˆ (¸ôeady independent of ° d ONLN d€ ä û ( äinstr ó¿ ° d ONLN d‡ û 1 )"uction timing, because it should r 0 ° d ONLN d 2 o )î
un without pr ·‡ ° d ONLN d o ˝ )= oblem on a wide range of 680x0 ° d ONLN d.
Several instr l ° d ONLN dÖ> ¡J= )7 uctions included in the instr [Ä ° d ONLN d¢>=Jµ )| uction set of the 68020 micr •‡ ° d ONLN dæ>µJƒ )xopr ‚Ä ° d ONLN d¡>ƒJ¯ ) ocessor wer Ÿ† ° d ONLN dÃ>¯Jˇ )4e ° d ONLN dŒK äW ç (T är E ° d ONLN dœK éW ª ) emoved fr |† ° d ONLN dÿK ªW )- om the instr ª@ ° d ONLN d‰K Wõ )5'uction sets of the 68030 and 68040 micr /¿ ° d ONLN d KúW´ )¨opr l` ° d ONLN d K´W )ocessors. The deleted . ° d ONLN d $X äd ü (a äinstr l ° d ONLN d )X üd )
uctions ar >` ° d ONLN d 3X d „ )+e the ,
Courier >` ° d ONLN d 9X „d )CALLM >` ° d ONLN d >Xd ) and >` ° d ONLN d CXd( )RTM >` ° d ONLN d FX(d? ) instr *` ° d ONLN d LX?dî )uctions, which wer ¸¿ ° d ONLN d ^Xìd )T e intended for use in module . ° d ONLN d {e äq “ (n äcalls. These instr X ° d ONLN d çe ”q ˛ )I
uctions ar √ ° d ONLN d óe ˛q∂ )+'e not supported by the 68LC040 Emulator ·Ä ° d ONLN d æe∂q )∏, and any attempt ° d ONLN d —r ä~ È ({ äto execute them will r ˝† ° d ONLN d Ár È~J )_esult in an illegal instr ”@ ° d ONLN d
rK~¬ )buction exception. However h¿ ° d ONLN d
r¬~ )w, because these ° d ONLN d
) äã û (à äinstr ó¿ ° d ONLN d
. ûã … )
uctions ar ¿ ° d ONLN d
8 ã Ï ),e not pr ¿ ° d ONLN d
@ ÏãS )"esent in any 680x0 micr 5@ ° d ONLN d
WSãb )gopr q‡ ° d ONLN d
Zbã∏ )ocessor either befor e ° d ONLN d
n∏ã )Ve or after the 68020, ° d ONLN d
Ñå äò † (ï äthis r ˛ ° d ONLN d
äå †ò ) estriction is not likely to pr R† ° d ONLN d
®åòw )wesent compatibility pr ˆ† ° d ONLN d
æåwò· )`oblems for your softwar U‡ ° d ONLN d
’å‚òÈ )ke. ˇ$ú @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-10
)BThe 68LC040 Emulator 4 ^ *¿¯
j * p¯ 4 j * p¯ k l k¯
ˇ·ˇ‚7^
° d ONLN d \ l j ( f l Unsupported Instruction Features ˇˇˇˇˇˇ ‘@ ( fÒ1
° d ONLN d " p l | £ ( y l
Several instr l ° d ONLN d / p £ | ‚ )7uction or addr π† ° d ONLN d = p ‚ |! )?
essing mode fi Å¿ ° d ONLN d K p" |Ç )@elds and encodings ar · ° d ONLN d ` pÇ |– )`e documented by ° d ONLN d p } l â á ( Ü lMotor Á† ° d ONLN d u } á â ¶ )ola as r GÄ ° d ONLN d } } ß â4 ) eserved. In addition, many instr £† ° d ONLN d ù }4 â_ )ç
esults dif E ° d ONLN dQ óm £ç )(fers acr GÄ ° d ONLN dY óç £— ) oss the various ° d ONLN di § l ∞
( ≠ l#members of the 680x0 family of micr ц ° d ONLN då §
∞ )°opr ¡@ ° d ONLN dè § ∞÷ )'ocessors and under the 68LC040 Emulator ⇠° d ONLN d∂ §÷ ∞Ì )∫. It is ° d ONLN dæ ± l Ω ( ∫ l"unlikely that any existing softwar ∑¿ ° d ONLN d‡ ± Ωò )î#e intentionally depends on either r ” ° d ONLN d ±ò Ω¬ )ò eserved fi Æ` ° d ONLN d
±√ Ω„ )+elds or ° d ONLN d æ l à ( « lundefi J† ° d ONLN d æ â † ) ned r F` ° d ONLN d æ † ˙ )esults. It is, however ¿ ° d ONLN d6 æ ˙ )Z, r ”¿ ° d ONLN d9 æ o )emotely possible that thr ,‡ ° d ONLN dR æp ö )n ough a pr — ° d ONLN d[ æö › )*
ogramming err ∫Ä ° d ONLN dh æ› Ë )Cor ° d ONLN dk À l ◊ ß ( ‘ l some softwar ¥‡ ° d ONLN dw À ß ◊5 ); e might be depending on these r ° d ONLN dñ À6 ◊à )è!esults and hence might behave dif ´ ° d ONLN d∑ Àà ◊ÿ )ñfer çÄ ° d ONLN d∫ Àÿ ◊ ) ently ° d ONLN d¿ ÿ l ‰ í ( · lunder th ƒ@ ° d ONLN d» ÿ í ‰ ¶ )&e em ´Ä ° d ONLN dà ÿ ß ‰. ) ulator than on an actual 680x0.
* ¯ 4 * ¯ l¯
ˇ·ˇ‚7^
° d ONLN dÏ ı l œ ( ˇ lInstruction Caches ˇˇˇˇˇˇ ‘@ ( ˇÒ1
° d ONLN d l ‹ ( lThe operation of the instr ü¿ ° d ONLN d ‹` )p uction cache in the 68040 micr
° d ONLN d8 ap )Öopr I† ° d ONLN d; pÎ ) ocessor is not supported by ° d ONLN dW l" Œ ( lthe 68LC040 Emulator \Ä ° d ONLN dk Œ"M )b , although all of the bits in th j ° d ONLN dãM"` )e Ca ¿ ° d ONLN dè`"j )ch ` ° d ONLN dëk"~ ) e Co ‚Ä ° d ONLN dï~"ã )ntr ª@ ° d ONLN dòã"ê )
o 0¿ ° d ONLN dôë"° )l Re ¿ ° d ONLN dù¢"Ì )gister (CACR) an ‡@ ° d ONLN d≠Ì"ı )Kd ° d ONLN dØ# l/ x (, lCa ó ° d ONLN d±# x/ Ç ) ch ÿ† ° d ONLN d≥# Ç/ â )
e √‡ ° d ONLN dµ# â/ ñ )Ad ¶‡ ° d ONLN d∑# ó/ ° )dr ᆠ° d ONLN dπ# °/ ™ )
es é@ ° d ONLN dª# ™/ º ) s Re ¬‡ ° d ONLN dø# º/ )gister (CAAR) r 6@ ° d ONLN dŒ#/O )Felated to the instr = ° d ONLN d·#O/ë )Muction cache ar fÄ ° d ONLN d#ë/» )B e supported. ` ° d ONLN d¸#…/◊ )8 In ° d ONLN d 0 l<5 (9 l-general, of course, your code should not addr \† ° d ONLN d-05<t )…ess the cache r > ° d ONLN d<0t<• )? egisters dir A ° d ONLN dH0•<π )1ectly ° d ONLN dM0π<ª ). ˇˇÛ+ ° d ONLN dOB lN r (K lB õ¿ ° d ONLN dPB rN )$ecause both emulated code and data r 7Ç ° d ONLN dtBN¯ )ß1eside in the PowerPC data cache, the performance ° d ONLN d•O l[ Ü (X lbenefi y ° d ONLN d´O á[ ) ts associated with caching ar { ° d ONLN d»O[( )~
e still pr D` ° d ONLN d“O)[ÿ )$'esent. Indeed, the caching scheme used ° d ONLN d˘\ lh ë (e ltranspar äÄ ° d ONLN d\ ëh )% ently by the 68LC040 Emulator r ’ ° d ONLN d \ h≤ )è#esults in a higher level of softwar ° d ONLN dC\≥h˜ )ìe compatibility ° d ONLN dSi lu (r l"than is found on actual 680x0 micr K` ° d ONLN duiu )òopr à ° d ONLN dxiu≈ )(ocessors. Some older versions of softwar ° d ONLN d†iΔu· )≥e that ° d ONLN d®v lÇ t ( lar E ° d ONLN d™v uÇa ) 3e incompatible with the 68040 cache mechanism can r ^‡ ° d ONLN d›vaÇû )Ï
un without pr † ° d ONLN dÍvüÇ⁄ )> oblem under ° d ONLN d˜É lè u (å lth ì¿ ° d ONLN d˘É uè â ) e em { ° d ONLN d˝É äè § )ulator W† ° d ONLN dÉ §è ¶ ). ° d ONLN dï l° (û l&Requests to invalidate the 68040 instr £` ° d ONLN d+ï°R )§uction cache ar Ç ° d ONLN d:ïR°p )Be ignor ô‡ ° d ONLN dAïq°Ó ) ed by the 68LC040 Emulator rÄ ° d ONLN d[ïÓ°Û )}. ° d ONLN d]¢ lÆ ï (´ lHowever † ° d ONLN dd¢ ïÆ` ))0, you should continue to issue those calls in or † ° d ONLN dî¢`ÆÄ )Àder to r mÄ ° d ONLN dú¢ÄÆË ) emain compatible with ° d ONLN d≤Ø lª (∏ l 680x0-based Macintosh computers
† ° d ONLN d—ت )ô. Mor ∫` ° d ONLN d÷Ø ª4 )eover û† ° d ONLN d€Ø4ªg )
, all cache fl ˜† ° d ONLN dÈØgªã )3ushing r õ ° d ONLN dÒØ媣 )%equir ≤@ ° d ONLN dˆØ£ªÎ )ed for PowerPC ° d ONLN dº l» É (≈ lcode À ° d ONLN d
º É» ≤ )
fragments ° d ONLN dº ≥»∫ )07is performed automatically by the Code Fragment Manager s ° d ONLN dKºπ»ª (≈π.
÷ *‰¯ 4◊ *‰¯
° d ONLN dM’ l‡ (› lNote
ˇ·ˇ‚7^
° d ONLN dR‚ lÓ Û * For details on invalidating the (¿ ° d ONLN dr‚ ÙÓ )à680x0 —` ° d ONLN dx‚Ó# )instr È ° d ONLN d}‚#Ó£ ) uction cache, see the chapter ° d ONLN dõÓ l˙ (˜ l!“Memory Management Utilities” in à¿ ° d ONLN dºÓ ˙y )†Inside Macintosh: Memory æ ° d ONLN d‘Óx˙z )l. ,
Zapf Dingbats
> ° d ONLN d÷ÒÄ˘Ü )u
° d ONLN dÿˇ l o ( lI fiÄ ° d ONLN dŸˇ o ˆ ) t is possible, although unlikely ‡ ° d ONLN d˘ˇ ˆ Ï )á:, that an application depends on the ability of the 68040 ° d ONLN d3 l Ä ( linstr ó¿ ° d ONLN d8 Ä » )uction cache to r ˘ ° d ONLN dI »5 )Hetain a stale copy of instr »` ° d ONLN dd 6Ë )n'uctions after the RAM copy of them has ° d ONLN dã l%I (" l0been changed. Such applications do not work corr v@ ° d ONLN dªI%‡ )›!ectly with 68000-based Macintosh ° d ONLN d‹& l2c (/ l7computers (for example, the Macintosh Plus, SE, Classic
is used to disable caching. ù‡ ° d ONLN d û@ ·L ˙ )uAs a r g ° d ONLN d §@ ˚L ).esult, this nonemulated behavior should not pr ¿ ° d ONLN d “@ÀL˜ )–
esent any ° d ONLN d ‹M lY » (V lnew compatibility pr 2 ° d ONLN d M …Y Î )]oblems.
w *~¯ 4x *~¯ y ly¯
ˇ·ˇ‚7^
° d ONLN d ¯j lx Ù (t lAddress Error Exceptions ˇˇˇˇˇˇ ‘@ (tÒ1
° d ONLN d
~ lä r (á lT µ¿ ° d ONLN d
~ qä é )o impr .¿ ° d ONLN d
~ èä- ) #ove the performance of branch instr 9Ä ° d ONLN d
<~-ä— )û%uctions, the 68LC040 Emulator is not ° d ONLN d
aã lóC (î l/completely compatible with an actual 68040 micr I‡ ° d ONLN d
êãDóS )ÿopr ÜÄ ° d ONLN d
ìãSó– )ocessor when detecting and ° d ONLN d
Æò l§ o (° lr E ° d ONLN d
Øò p§ ≠ )
eporting addr Ć ° d ONLN d
ºò ≠§ … )=ess err ≈Ä ° d ONLN d
√ò …§ ) or exceptions. , ° d ONLN d
“ò § )@A f¿ ° d ONLN d
”ò§B ) 680x0 micr Å ° d ONLN d
fiòB§Q )2opr Ω† ° d ONLN d
·òQ§∏ )ocessor checks for addr œ@ ° d ONLN d
¯ò∏§‘ )gess err ° d ONLN d
ˇò’§Â ) ors ° d ONLN d • l± É (Æ lbefor _† ° d ONLN d • ɱD ),e completing the execution of a branch instr ì ° d ONLN d 4•D±| )¡uction; if it fi Ô¿ ° d ONLN d D•|±± )8 nds an addr Á¿ ° d ONLN d O•±±Õ )5ess err ,† ° d ONLN d V•Œ±◊ ) or ◊` ° d ONLN d X•÷±Î ), the ° d ONLN d ^≤ læ Ä (ª lmicr q† ° d ONLN d b≤ Äæ è )opr Æ@ ° d ONLN d e≤ èæ ∂ ) ocessor r Ñ¿ ° d ONLN d n≤ ∂æ )'eports (in an addr ìÄ ° d ONLN d Ä≤æ! )Oess err ÿ` ° d ONLN d á≤!æõ ) or exception frame that it cr ˙† ° d ONLN d §≤õæÓ )zeates on the stack) ˇ(í @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ äThe 68LC040 Emulator
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä hE ( e ä+the PC at the beginning of the branch instr ù‡ ° d ONLN d + \E h )ª*uction. By contrast, the 68LC040 Emulator ° d ONLN d U i ä u Œ ( r ächecks for addr Ä ° d ONLN d d i Œ u Í )Dess err ≈ ° d ONLN d k i Í u ˙ ) ors Í ° d ONLN d o i ˙ u )after <¿ ° d ONLN d t i
° d ONLN d˙ Œ ä ⁄6 ( ◊ ä$The 68LC040 Emulator handles bus err r¿ ° d ONLN d Œ6 ⁄£ )¨or exceptions slightly dif ä@ ° d ONLN d8 Œ£ ⁄Ø )mfer l¿ ° d ONLN d; ŒØ ⁄ ) ently than does a r † ° d ONLN dN Œ ⁄ )Real ° d ONLN dR € ä Á π ( ‰ ä
680x0 micr @ ° d ONLN d\ € ∫ Á … )0opr V‡ ° d ONLN d_ € … Á È )ocessor + ° d ONLN df € È ÁN ) . If you install a bus err ¿ ° d ONLN dÄ €N Á| )e
or handler M‡ ° d ONLN dä €| Á˜ )., you might need to be awar fi` ° d ONLN d• €˜ Á ){e of ° d ONLN d™ Ë ä Ù Ø ( Ò ä these dif ` ° d ONLN d≥ Ë ∞ Ù º )&fer ‡ ° d ONLN d∂ Ë ª Ù ÿ ) ences. ’ ° d ONLN dΩ Ë ÿ Ù fi ) Y ï† ° d ONLN dæ Ë fi ÙF )ou also need to be awar “† ° d ONLN d’ ËF Ù~ )he of these dif Ù ° d ONLN d„ Ë~ Ùä )8fer ÷Ä ° d ONLN dÊ Ëä Ù ) ences when debugging your ° d ONLN d ı ä ´ ( ˛ äsoftwar ‰¿ ° d ONLN d ı ´Ü )!0e, because most debuggers need to handle bus err G‡ ° d ONLN d7 ıრ)‹or exceptions. ° d ONLN dF ä ˙ ( äThe 68LC040 Emulator cr ≠Ä ° d ONLN d] ˙Ó )p5eates format $B exception frames when generating and ° d ONLN dí ä ” ( ähandling bus err º¿ ° d ONLN d¢ ” )I ors. However ÓÄ ° d ONLN dÆ : ); , several fi ÿ ° d ONLN d∫; — )-"elds within the exception frame ar ä¿ ° d ONLN d‹“ )ó
e documented ° d ONLN dÈ! ä- ≥ (* äby Motor ~` ° d ONLN dÒ! ≥- Ó ))ola as interna £ ° d ONLN dˇ! Ó- ˘ );l fi ° d ONLN d! ˙- ) elds, ¢‡ ° d ONLN d!-y ) and the contents of thos ê‡ ° d ONLN d!!z-á )le fi Á@ ° d ONLN d%!á-† )
elds a r ° d ONLN d+!°-§ )r 7 ° d ONLN d,!•-ı )e very likely to dif uÄ ° d ONLN d@!ı- )Pfer ° d ONLN dD. ä:ˇ (7 äQbetween the 68LC040 Emulator exception stack frame and the exception stack frame ° d ONLN dï; äG í *
:frame is compatible with the internal state information cr »` ° d ONLN d~UÜaÓ )¸eated by the 680x0 micr » ° d ONLN dïUÓaÛ )ho =† ° d ONLN dñUÙa˜ )- ° d ONLN dòb än ì (k äpr G ° d ONLN döb în )
ocessors, the exception frame cr ,@ ° d ONLN d∫b nQ )å eated by th H ° d ONLN d≈bQne )1e em /` ° d ONLN d…bfn ))ulator intentionally uses a value in the ° d ONLN dÚo ä{ ë (x äV ú` ° d ONLN dÛo ê{ € )ersion Number fi ?Ä ° d ONLN do ‹{{ )L&eld of the exception frame that is dif ]‡ ° d ONLN d)o{{á )üfer @` ° d ONLN d,oá{û ) ent fr ∂† ° d ONLN d2oû{˝ )om the value put ther *‡ ° d ONLN dGo˛{ )`e by ° d ONLN dL| äà à (Ö äany 680x0 micr ˙¿ ° d ONLN dZ| Ãà € )Bopr 7` ° d ONLN d]| ‹à ¸ )ocessor Ä ° d ONLN dd| ¸à ˛ ) . ° d ONLN dfé äö “ (ó äIn addition, ther c¿ ° d ONLN dwé “ö ‚ )He ar r` ° d ONLN d{é ‚öK )e several documented fi π† ° d ONLN díéKöö )ields of the bus err ∏ ° d ONLN d•éöö )Oor exception frame that ° d ONLN dΩõ äß — (§ ähave slightly dif ¿ ° d ONLN dŒõ “ß fi )Hfer ˆ@ ° d ONLN d—õ ›ß ) ent values in th ΩÄ ° d ONLN d·õ!ß5 )De em §¿ ° d ONLN dÂõ6ßË )'ulator than on a 680x0-based Macintosh ° d ONLN d ® ä¥ ¥ (± äcomputer Ñ@ ° d ONLN d® ¥¥ π )*. %‡ ° d ONLN d® π¥ )As long as bus err rÄ ° d ONLN d(®¥À )O+or exception handlers do not modify these fi ÷Ä ° d ONLN dT®À¥ )√elds, it is still . ° d ONLN dfµ ä¡ fi (æ äpossible to use the ,
Courier ° d ONLN dzµ fi¡ )TRTE ° d ONLN d}µ ¡ ) instr l ° d ONLN dɵ¡¥ ))uction to continue execution of the instr X ° d ONLN d¨µ¥¡ )≠uction that caused . ° d ONLN dø¬ äŒ (À ä the exception. In particular ·† ° d ONLN d€¬ Œ+ )v
, the PC fi Ï` ° d ONLN dʬ+Œ )+2eld of the exception frame might not point to the ° d ONLN dœ ä€ (ÿ ä exact beginning of the instr ó¿ ° d ONLN d4œ€ )x@uction that generated the exception. Instead, it might point to ° d ONLN dt‹ äËR ( ä.some location near the beginning of that instr ÊÄ ° d ONLN d¢‹RËr )»uction. q ° d ONLN d™‹sË‘ )!Also, the Stage B addr #¿ ° d ONLN d¿‹’ËÍ )bess fi Ù ° d ONLN dΔ‹ÍË
)eld and ° d ONLN dŒÈ äı (Ú ä the Stage B and Stage C instr J¿ ° d ONLN dÎÈ ıC )
uction pipe fi ˆ¿ ° d ONLN d˘ÈCı¯ ):)elds might not contain valid information. ° d ONLN d #˚ ä ® ( äFinally
° d ONLN d *˚ ® Ω ) , the j` ° d ONLN d 0˚ Ω )Special Status W ‘Ä ° d ONLN d @˚ )Hor ° d ONLN d B˚A )
d (SSW) dif |` ° d ONLN d M˚A” )2 fers under the 68LC040 Emulator VÄ ° d ONLN d l˚” )í. The 68LC040 ° d ONLN d z äN ( ä+Emulator does not distinguish between instr ‹ ° d ONLN d •NÙ )ƒ&uction space and data space accesses; ° d ONLN d À ä! Ù ( äinstead, it converts instr z ° d ONLN d  Ù!s )j uction fetches to data space r fl ° d ONLN d
s!å )eads. £ ° d ONLN d
å!• )As a r l` ° d ONLN d
¶! )esult, the FC2–FC0 fi €@ ° d ONLN d
$! )[eld ° d ONLN d
(" ä.à (+ ä;always indicates either a supervisor or a user data space r øÄ ° d ONLN d
c"à.ò )˛efer k† ° d ONLN d
g"ô.Ò )ence. In addition, th ï† ° d ONLN d
|"Ò.¯ )Xe ° d ONLN d
~/ ä; ó (8 äem † ° d ONLN d
Ä/ ò;} )6ulator never sets the FC, FB, or RM bits, and it ignor Ä ° d ONLN d
∂/}; )Â"es the RC and RB bits. The DF bit ° d ONLN d
ÿ< äH (E äis fully supported, however E ° d ONLN d
Û<HR )z, allowing both pr @ ° d ONLN d <SHÙ )O#ogram completion of bus cycles and . ° d ONLN d (I äU é (R är R` ° d ONLN d )I éU ó )er >` ° d ONLN d +I óU ) unning of bus cycles with the >` ° d ONLN d IIU+ )ÇRTE >` ° d ONLN d LI+UB ) instr *` ° d ONLN d RIBU )-uction. The 68LC040 Emulator also puts valid . ° d ONLN d V äb (_ ä values in the RM and SIZ bits.
Ä Há 4Å Há Ç äÇ
ˇ·ˇ‚7^
° d ONLN d ûs äÅ. * Memory-Mapped I/O Locations ˇˇˇˇˇˇ ‘@ (}1
° d ONLN d ªá äì8 (ê ä(In general, most applications do not dir ü ° d ONLN d „á8ì˝ )Æ*ectly access memory-mapped I/O locations. ° d ONLN d
î ä†Å (ù ä9Instead, they call device drivers or other system softwar Å¿ ° d ONLN d Fîņå )˜e r ê` ° d ONLN d Iîå†Ò ) outines to perform the ° d ONLN d `° ä≠ ç (™ är E ° d ONLN d a° é≠
)equested I/O operations. Fo ° d ONLN d |° ≠ô )}"r code (such as a device driver) t ˇ¿ ° d ONLN d û°ô≠µ )éhat do $¿ ° d ONLN d §°∂≠ø ) es +` ° d ONLN d ¶°ø≠Œ ) dir tÄ ° d ONLN d ™°Œ≠ )
ectly access ° d ONLN d ∑Æ ä∫, (∑ ä!memory-mapped I/O locations, ther c ° d ONLN d ÿÆ,∫< )¢e ar q¿ ° d ONLN d ‹Æ<∫˝ ),e a number of compatibility issues. In some ˇ!‚ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-12
)BThe 68LC040 Emulator 4 ^ *¿¯
° d ONLN d \ l h ˙ ( e l cases, the 680x0 emulation envir ß@ ° d ONLN d \ ˙ hÛ )é6onment might not perform some write operations that a ° d ONLN d V i l u o ( r lr E ° d ONLN d W i p u » )eal 680x0 performs: ,
Zapf Dingbats
° d ONLN d l l Ü q ( Ö ln
. ° d ONLN d n | x à å ) The ,
Courier ° d ONLN d r | å à § )BSET ° d ONLN d v | § à π ) and ° d ONLN d { | π à — )BCLR ° d ONLN d | — à Ë ) instr l ° d ONLN d Ö | Ë àÌ )<uctions might not write back an operand if none of the bits . ° d ONLN d ¡ à x î â ( ë xwer e† ° d ONLN d ƒ à â î œ )e changed as a r ∏¿ ° d ONLN d ‘ à œ î/ )Fesult of the operation.
° d ONLN d Ï ù l § q ( £ ln
. ° d ONLN d Ó ö x ¶ Ì ) Some memory-to-memory ° d ONLN d ö Ì ¶ )uMOVE ° d ONLN d ö ¶ ) instr l ° d ONLN d ö ¶Â )-uctions might not write to memory if the sour >` ° d ONLN d; ö ¶ )…ce . ° d ONLN d> ¶ x ≤ ‘ ( Ø xand destination addr ˘¿ ° d ONLN dR ¶ ‘ ≤ ı )\esses ar â ° d ONLN dZ ¶ ˆ ≤' )" e the same. ° d ONLN df ∑ l √ r ( ¿ lY @Ä ° d ONLN dg ∑ r √W )3ou might need to modify your application to use dif ™Ä ° d ONLN dö ∑W √c )Âfer ç ° d ONLN dù ∑c √¬ ) ent sequences of instr Ñ@ ° d ONLN d≥ ∑¬ √Ô )_ uctions to ° d ONLN dæ ƒ l –¡ ( Õ lMperform the operations if an I/O device was expecting these write bus cycles. ˇˇÜ . ° d ONLN d ÷ l ‚ *The ˇ˛íT ° d ONLN d ÷ Ä ‚ í )TAS ˇˇÜ ° d ONLN d ÷ í ‚ ñ ), ˇ˛íT å8 ° d ONLN d ÷ ñ ‚ ® )CAS ˇˇÜ å8 ° d ONLN d ÷ ® ‚ ø ), and ˇ˛íT òp ° d ONLN d ÷ ø ‚ ◊ )CAS2 ˇˇÜ òp ° d ONLN d" ÷ ◊ ‚ Ì ) instr
pı )Vesult, an alternate bus master type of I/O device might be allowed to modify a memory ° d ONLN dª l# Õ ( llocation between the r 1` ° d ONLN d— Œ#O )b ead and the write operations. ° d ONLN dÔ) l5P (2 l3The 68020 and 68030 bus interface supports a featur ñ† ° d ONLN d")P5s )‰ e called ܆ ° d ONLN d+)t5à )$dynamic bus sizing _† ° d ONLN d=)Õ5„ )Y that ° d ONLN dC6 lB” (? lSallows 8- or 16-bit-wide I/O devices to work with the 32-bit-wide data bus. If the ° d ONLN dñC lO u *
pr G ° d ONLN dòC vO › )
ocessor has a memory r ‡ ° d ONLN dÆC fiOz )h$equest for a data width that was lar h@ ° d ONLN d“CzOÔ )úger than the data width of ° d ONLN dÌP l\e (Y l8the device connected to the bus, the memory interface br /` ° d ONLN d%Pf\ê )˙
eaks the r gÄ ° d ONLN d/Pê\Î )*equest into multiple ° d ONLN dD] li o (f lr E ° d ONLN dE] pi ∞ )equests that ar P ° d ONLN dT] ∞iç )@5e the width of the device. For example, if a 32-bit r ≥† ° d ONLN dâ]çi£ )›ead r fi ° d ONLN dé]£iÚ )equest is made to ° d ONLN d†j lv∫ (s lMan 8-bit device, the memory interface actually performs four separate 8-bit r Æ ° d ONLN dÌj∫v€ (s∫eads to ° d ONLN dıw lÉ (Ä l%assemble the 32-bit data. This featur VÄ ° d ONLN dw Én )üe cannot be emulated. ¿ ° d ONLN d0wnÉ› )cAny application or other ° d ONLN dIÑ lê ç (ç lsoftwar ‰¿ ° d ONLN dPÑ çê )! e that depends upon this featur ° d ONLN doÑêm )ãe must to be modifi ú† ° d ONLN dÇÑmê“ )Ued to use separate instr f¿ ° d ONLN döÑ”êı )fuctions ° d ONLN d¢ë lù$ (ö l*to access and assemble each piece of data. ° d ONLN dÕ£ lØd *8The 68020 and 68030 bus interface also supports a featur ±Ä ° d ONLN d£dØá )¯ e called °Ä ° d ONLN d£àØ» )$
byte smearing VÄ ° d ONLN d£…Øfl )A that ° d ONLN d!∞ lºá (π lBallows 8- or 16-bit data to be duplicated on a write operation acr q ° d ONLN dc∞áºfl (πáoss all 32 bits of the ° d ONLN d{Ω l… œ (Δ ldata bus. The 68040 pr ¨¿ ° d ONLN dëΩ œ…l )c$ocessor does not support this featur 7` ° d ONLN dµΩm…¶ )ûe. This featur ƒÄ ° d ONLN d√Ω¶…⁄ )9 e cannot be ° d ONLN dœ l÷ ˚ (” l emulated, but solutions that wer ` ° d ONLN dÔ ¸÷fi )ê3e used for the 68040 should be compatible with the ° d ONLN d"◊ l„ æ (‡ l68LC040 Emulator ˇ ° d ONLN d2◊ Ω„ ø )Q. . ° d ONLN d4È lı ˛ (Ú l The 68020, 68030, and 68040 micr R` ° d ONLN dTÈ ˛ı
)íopr $¿ ° d ONLN dWÈ
ıD ) ocessors defi $¿ ° d ONLN ddÈDıb )7ne the $¿ ° d ONLN dkÈbıt ) NOP ˜ ° d ONLN dnÈsıä ) instr „ ° d ONLN dtÈäıË )uction as having the . ° d ONLN d∠l t (ˇ lef o‡ ° d ONLN d㈠t Ø )fect of synchr ≠Ä ° d ONLN dôˆ ØÛ );Konizing the pipeline and waiting for all prior bus operations to complete. ° d ONLN d‰ l ( lMThe 68020 and 68030 have a very small pipeline, and bus operations normally fi u ° d ONLN d 2À‡ ( Ànish ° d ONLN d 8 l π ( lsoon after they ar }` ° d ONLN d J π
)Me issued. However ¢Ä ° d ONLN d [
ì )Q , the 68040 and the PowerPC ar B` ° d ONLN d yî ∫ )ä chitectur ˜ ° d ONLN d Ç∫ ˆ )&
e let memory . ° d ONLN d è l) (& l)operations be queued and issued out of or R` ° d ONLN d ∏ )/ )¥der ï ° d ONLN d ª .)é ). Because of this, the ï ° d ONLN d “ é)† )`NOP g` ° d ONLN d ’ †)∑ ) instr S` ° d ONLN d € ∑)‘ )uction . ° d ONLN d „* l6 ‹ (3 lmight be needed to ensur Ú@ ° d ONLN d ˚* ‹6Ê )p:e that accesses to memory-mapped I/O devices occur in the . ° d ONLN d
57 lC v (@ lpr R` ° d ONLN d
77 vC ï )
oper or $¿ ° d ONLN d
>7 ïC § ) der g` ° d ONLN d
A7 £Cf )*. The 68LC040 Emulator supports the featur 9¿ ° d ONLN d
k7fCé )√
es of the 9¿ ° d ONLN d
u7éC† )(NOP ° d ONLN d
x7†C∑ ) instr ¯ ° d ONLN d
~7∂C÷ )uction. ˇˇÖx ° d ONLN d
áD lP ı (M l Any application that includes ˇ˛êh ï‡ ° d ONLN d
•D ıP )âNOP ˇˇÖx h@ ° d ONLN d
®DP ) instr Ÿ∏ ° d ONLN d
ÆD P˜ )0uctions should be compatible with all Macintosh . ° d ONLN d
fiQ l] ù (Z l
computers. ° d ONLN d
Èc lo+ *,If an I/O device causes a bus timeout that r §Ä ° d ONLN d c+ox )øesults in a bus err ¿ ° d ONLN d (cyoÎ )Nor exception, it might not ° d ONLN d Dp l| ˇ (y l be possible for the PowerPC micr ¢‡ ° d ONLN d dp ˇ| )ìopr flÄ ° d ONLN d gp|] )ocessor—and ther ÄÄ ° d ONLN d wp^|o )Pefor ÿÄ ° d ONLN d {po|‚ )e the 68LC040 Emulator— ° d ONLN d ì} lâ Ù (Ü l to determine the memory addr ∂ ° d ONLN d Ø} Ùâ’ )à6ess that was accessed. If all locations within a 4 KB ° d ONLN d Êä lñ (ì l'I/O page consistently time out, this pr ‹‡ ° d ONLN d
° d ONLN d ô ä • ö ( ¢ äAn ò† ° d ONLN d ô ö • ) instruction set architecture -† ° d ONLN d + ô •^ )z is the set of instr ⁄Ä ° d ONLN d ? ô^ •Ñ )J uctions r EÄ ° d ONLN d H ôÖ •˜ )'ecognized by a particular ° d ONLN d b ¶ ä ≤ ì ( Ø äpr G ° d ONLN d d ¶ î ≤ ˜ )
ocessor or family of pr Y ° d ONLN d { ¶ ˜ ≤& )c ocessors. T H@ ° d ONLN d Ü ¶' ≤4 )0he c@ ° d ONLN d â ¶4 ≤ô )
Mixed Mode Manager @ ° d ONLN d õ ¶ö ≤Ê )f is the part of the ° d ONLN d Ø ≥ ä ø ˝ ( º äMacintosh system softwar 3` ° d ONLN d « ≥ ˛ øB )te that manages @ ° d ONLN d ÷ ≥C øÜ )E
mode switches ч ° d ONLN d „ ≥Ü øfl )C between code in dif É` ° d ONLN d ˜ ≥fl øÎ )Yfer e‡ ° d ONLN d ˙ ≥Î ø˚ ) ent ° d ONLN d ˛ ¿ ä à û ( … äinstr ó¿ ° d ONLN d ¿ û à ‘ )
uction set ar é¿ ° d ONLN d ¿ ‘ Ã ˙ )6 chitectur CÄ ° d ONLN d ¿ ˚ Ã )'=es, switching the execution context between the CPU’s native ° d ONLN dV Õ ä ŸN ( ÷ ä(PowerPC context and the 68LC040 Emulator ™¿ ° d ONLN d~ ÕN Ÿ» )ƒ. The 68LC040 Emulator is r
` ° d ONLN dô Õ… Ÿ ){esponsible for ° d ONLN d® ⁄ ä Ê$ ( „ ä$handling all code in the 680x0 instr „ ° d ONLN dà ⁄$ Ê )ö7uction set. This includes existing 680x0 applications, ° d ONLN d Á ä Û≈ ( äGdevice drivers, system extensions, and even parts of the system softwar ܇ ° d ONLN dJ Á≈ Û ( ≈e itself that have ° d ONLN d] Ù ä Δ ( ˝ änot yet been r ’† ° d ONLN dk Ù Δ [ )<!ewritten to use the PowerPC instr fi¿ ° d ONLN då Ù[ à )ï uction set. ° d ONLN dò ä ◊ ( äMode switches ar ° d ONLN d® ÿ „ )Ne r *¿ ° d ONLN d´ „ ˙ ) equir B ° d ONLN d∞ ˙ü )%ed not only when the user switches fr ∞ ° d ONLN d’ü¸ )•om an emulated to a ° d ONLN dÈ ä ( äXnative application (or vice versa), but also when any application calls a system softwar -` ° d ONLN dA ( e ° d ONLN dC ä, ç () är E ° d ONLN dD é,J )-outine or any other code that exists in a dif ±‡ ° d ONLN dq J,V )ºfer î` ° d ONLN dt V,z ) ent instr Ä ° d ONLN d} {,˜ )% uction set. For example, the ° d ONLN dö- ä9 (6 äMemory Manager has been r €¿ ° d ONLN d≥- 9l )eimplemented in the fi –Ä ° d ONLN d…-m9Ï )d rst version of system softwar (Ä ° d ONLN dÊ-Ì9 )Äe for ° d ONLN dÏ: äF ¿ (C ä
PowerPC pr z ° d ONLN dˆ: ¿F ‡ )6ocessor fi ° d ONLN d˝: ‡F˚ ) ;-based Macintosh computers as native PowerPC code. When an ° d ONLN d8G äS (P ä existing 680x0 application r a ° d ONLN dTGSÌ )y1unning under the 68LC040 Emulator calls a Memory . ° d ONLN dÖT ä` ∏ (] ä Manager r R` ° d ONLN déT ∏` ¯ ).outine such as ,
Courier R` ° d ONLN dùT ¯`. )@ NewHandle R` ° d ONLN d¶T.`Ñ )6, a mode switch is r $¿ ° d ONLN d∫TÑ`õ )Vequir ˜ ° d ONLN døTö`˘ )ed to move out of the . ° d ONLN d’a äm é (j äe I† ° d ONLN d÷a èmM ))mulator and into the native PowerPC envir ` ° d ONLN dˇaNm
)ø&onment. Then, once the Memory Manager ° d ONLN d%n äz ç (w är E ° d ONLN d&n ézK )*outine completes, another mode switch is r Ó¿ ° d ONLN dPnKzb )Ωequir ° d ONLN dUncz )ed to r h@ ° d ONLN d\nz ) eturn to the 68LC040 Emulator ° d ONLN dz{ äáÖ (Ñ ä9and to allow the 680x0 application to continue executing. ° d ONLN d¥ç äô ≤ * Similarly õ@ ° d ONLN dΩç ±ô‚ )'A, PowerPC applications cause mode switches whenever they invoke r E@ ° d ONLN d˛ç„ô (ñ„outines ° d ONLN dö 䶈 (£ äUthat exist only as 680x0 code. For example, if a PowerPC application calls a part of ° d ONLN d\ß ä≥ — *
the Macintosh T ¯† ° d ONLN dkß –≥ˇ )FCoolbox or Operating System that has not been ported native, a mode ° d ONLN dØ¥ ä¿ ∑ (Ω ä switch is r j¿ ° d ONLN d∫¥ ∑¿ Œ )-equir Ç ° d ONLN dø¥ Œ¿ )
ed to move fr qÄ ° d ONLN dÃ¥ ¿_ );om the native envir s ° d ONLN dfl¥_¿∂ )Vonment to the envir o ° d ONLN dÚ¥∂¿ˆ )Wonment of the ° d ONLN d ¡ äÕ ‹ ( ä68LC040 Emulator ˇ ° d ONLN d¡ €Õ › )Q. ° d ONLN d” äfl˙ (‹ äPThe Mixed Mode Manager exists solely to manage these kinds of mode switches. It ° d ONLN db‡ äÏ< *
)makes it possible for the execution envir U ° d ONLN dã‡<Ï° )≤onment of PowerPC pr ¿ ° d ONLN dü‡¢Ï¬ )focessor t† ° d ONLN d¶‡¬Ï ) -based Macintosh ° d ONLN d∑Ì ä˘, (ˆ ä!computers to accommodate a mixtur ≈@ ° d ONLN dÿÌ,˘¸ )¢/e of 680x0 applications, PowerPC applications, ° d ONLN d˙ ä Ë ( ä680x0 system softwar ˆÄ ° d ONLN d˙ Ë` )^e, PowerPC system softwar ¡ ° d ONLN d4˙aª )ye, 680x0 executable r 'Ä ° d ONLN dI˙º‘ )[esour o¿ ° d ONLN dN˙‘ )
ces, PowerPC ° d ONLN d[ ä ø ( ä executable r t@ ° d ONLN dg ø ◊ )5esour ºÄ ° d ONLN dl ◊ )Eces, 680x0 device drivers, PowerPC device drivers, and so forth. The ° d ONLN d± ä ( äO68LC040 Emulator and the Mixed Mode Manager together allow both 680x0 code and ° d ONLN d ! ä-Z *
+PowerPC code to execute on the PowerPC micr > ° d ONLN d +![-j )—opr z¿ ° d ONLN d .!j-ä )ocessor N‡ ° d ONLN d 5!ä-å ) . ° d ONLN d 73 ä?ˇ (< äQThe Mixed Mode Manager is designed to hide, as much as possible, the hybrid natur ° d ONLN d à3 ? (< e of ° d ONLN d ç@ äL œ (I äthe mixed envir ` ° d ONLN d ú@ –Lh )F onment supported on PowerPC pr ߇ ° d ONLN d ∫@hLà )òocessor ¿ ° d ONLN d ¡@âL
)! -based Macintosh computers. ° d ONLN d ›M äY ¬ (V ä Occasionally Ï¿ ° d ONLN d ÈM ¡Y Ï )7 , however ˘` ° d ONLN d ÚM ÏY´ )+,, some executable code needs to interact dir m@ ° d ONLN d
M¨Y )¿ectly with the Mixed ° d ONLN d
3Z äf Ù (c äMode Manager to ensur æ ° d ONLN d
HZ Ùfù )j'e that a mode switch occurs at the corr W ° d ONLN d
oZûf¸ )™ect time. Because the ° d ONLN d
Ög äs (p äT68LC040 Emulator is designed to allow existing 680x0 applications and system softwar Ç ° d ONLN d
Ÿg s (p e ° d ONLN d
€t äÄ ˚ (} äto execute without modifi c† ° d ONLN d
, if you’r á ° d ONLN d Û≠ ¬π )%Me writing a native application, you might need to modify your application to ˇ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-14
)B
Mixed Mode 4 ^ *¿¯
° d ONLN d \ l h ( e l'make it compatible with the mixed envir ·@ ° d ONLN d ' \ h¢ )≥ onment of the system softwar Œ ° d ONLN d C \¢ h‰ )Ée for PowerPC ° d ONLN d Q i l u u ( r lpr G ° d ONLN d S i v u ñ )
ˇˇ‹. ˇ◊ ° d ONLN d¥ º l À ÿ ( « lCross-Mode Calls ˇˇˇˇˇˇ €r ( «1
° d ONLN dΔ “ l fil ( € l6The Mixed Mode Manager is intended to operate transpar …` ° d ONLN d¸ “l fiÙ ( €l ently to most applications and ° d ONLN d fi l Í Õ ( Á lother kinds of softwar @ ° d ONLN d1 fi Œ ÍE )b e. This means, in particular † ° d ONLN dM fiE Ív )w , that most /† ° d ONLN dY fiv Í¿ )1cross-mode calls ›¿ ° d ONLN di fi¿ Í€ )J (calls ° d ONLN dr Î l ˜ ≠ ( Ù lto code in a dif Á ° d ONLN dÇ Î ≠ ˜ π )Afer …† ° d ONLN dÖ Î π ˜ › ) ent instr >¿ ° d ONLN dé Î fi ˜ )%
uction set fr ↠° d ONLN dõ Î ˜K )4
om the caller k ° d ONLN d® ÎL ˜i ):’s instr ° d ONLN d∞ Îj ˜£ ) uction set) ar R ° d ONLN dæ Σ ˜“ )9 e detected ° d ONLN d… ¯ l˜ ( lUautomatically by the Mixed Mode Manager and handled without explicit intervention by ° d ONLN d l Ω *
the calling softwar L ° d ONLN d1 æ )RAe. For instance, when a 680x0 application calls a Memory Manager ° d ONLN dr l o ( lr E ° d ONLN ds p ˘ ) outine—which, as you have alr ë ° d ONLN dê ˘ fi )â3eady learned, exists as PowerPC code in the system ° d ONLN d√ l* ç (' lsoftwar ‰¿ ° d ONLN d ç* Ÿ )!e for PowerPC pr dÄ ° d ONLN d⁄ ⁄* ˙ )Mocessor »` ° d ONLN d· ˙*ô ) -based Macintosh computers—the T ¬Ä ° d ONLN d ô*‘ )ü rap Manager ° d ONLN d
+ l73 (4 l-dispatches to the code pointed to by the appr |† ° d ONLN d:+37Û )«.opriate entry in the trap dispatch table. For ° d ONLN dh8 lD o (A lr E ° d ONLN di8 pD Ø )outines that ar flÄ ° d ONLN dx8 ØD„ )?He implemented as native code, the entry in the trap dispatch table is a ° d ONLN d¿D lP • (M lpointer to a r ¨‡ ° d ONLN dŒD •P )9outine descriptor à ° d ONLN dflD P )K , a data str à@ ° d ONLN dÎD P5 ).uctur ° d ONLN dD6P„ )$e used by the Mixed Mode Manager to ° d ONLN dQ l] (Z l!encapsulate information about a r å‡ ° d ONLN d5Q]; )ï
outine. The fi ¿ ° d ONLN dCQ<]O );rst fi Ä ° d ONLN dIQP]v )
eld in a r „ ° d ONLN dSQv]€ )&outine descriptor is an ° d ONLN dk^ lj Õ (g lexecutable 680x0 instr o† ° d ONLN dÅ^ Õjó )a*uction that invokes the Mixed Mode Manager ¿ ° d ONLN d´^ójÍ ) . The Mixed Mode ° d ONLN dºk lwÒ (t lZManager handles all the details of switching to the native mode, calling the native code, ° d ONLN dw lÉ ô *
) the 680x0 r ) ° d ONLN dª„Ôì )3 outine. When the 680x0 code r m‡ ° d ONLN dÿ„ìÔ„ )Öeturns, the Mixed ° d ONLN dÍ l¸n (˘ l6Mode Manager switches back to the native PowerPC envir ° d ONLN d o¸Ô (˘o onment and the execution of ° d ONLN d <˝ l
( l"the PowerPC application continues.
*$¯ 4 *#¯
° d ONLN d _ l *Note
ˇ·ˇ‚7^
° d ONLN d d! l- } *
See ” ° d ONLN d h! }- ˙ )“The PowerPC Native Envir Ï ° d ONLN d Å! ˙-x )}onment” beginning on page :` ° d ONLN d õ!y-ã )1-19 é@ ° d ONLN d ü!ã-ç ) ° d ONLN d °- l9@ (6 l0for information about the native execution envir ‡ ° d ONLN d —-A9î )’onment, including ° d ONLN d „9 lE ≥ (B limport libraries. ,
Zapf Dingbats
† ° d ONLN d ı< πD ø )Mu
° d ONLN d ˜J lV ˝ (S l When writing PowerPC code, yo ¨` ° d ONLN d
J ˝VÊ )ë5u need to explicitly intervene in the mode-switching ° d ONLN d
IW lc u (` lpr G ° d ONLN d
KW vc› )
Nocess only when you execute code (or have code executed on your behalf) whose ° d ONLN d
ôd lp Ä (m linstr ó¿ ° d ONLN d
ûd Äp ∂ )
uction set ar é¿ ° d ONLN d
´d ∂p ‹ )6 chitectur CÄ ° d ONLN d
¥d ›p )'e might be dif h ° d ONLN d
¬dp& )=fer JÄ ° d ONLN d
≈d&p= ) ent fr ¿¿ ° d ONLN d
Àd=pÛ )*om that of the calling code. For example, ° d ONLN d
ıq l} È (z lwhenever you pass the addr —@ ° d ONLN d q È}5 )}ess of a callback r k@ ° d ONLN d "q6}‘ )M#outine to the Operating System or T Ú ° d ONLN d Eq”}ı )ùoolbox, ° d ONLN d M~ lä ⁄ (á l it’s possible that the instr
‡ ° d ONLN d i~ €ä )o
uction set ar ‡ ° d ONLN d v~ä7 )6 chitectur π† ° d ONLN d ~7ä• )&e of the code whose addr ° d ONLN d ó~¶ä“ )o
ess you ar *Ä ° d ONLN d °~“äŸ ),e ° d ONLN d £ã ló ¶ (î lpassing is dif î¿ ° d ONLN d ±ã ¶ó ≤ ):fer w@ ° d ONLN d ¥ã ≤ó … ) ent fr ÌÄ ° d ONLN d ∫ã …ó ˛ ) om the instr , ° d ONLN d Δã ˇó5 )6
uction set ar # ° d ONLN d ”ã5ó[ )6 chitectur ◊‡ ° d ONLN d ‹ã[óÅ )&
e of the r ç@ ° d ONLN d ÊãÇó∏ )' outine you’r Á† ° d ONLN d Úã∏ó„ )6
e passing ° d ONLN d ˝ò l§† (° lJit to. In such cases, you need to explicitly signal the type of code you’r ˝ ° d ONLN d Gò†§Î (°†e passing and its ° d ONLN d Y• l±Ù (Æ lUcalling conventions. Otherwise, the Mixed Mode Manager might not be called to make a ° d ONLN d Æ≤ læ o *
r E ° d ONLN d Ø≤ pæ á )equir \@ ° d ONLN d ¥≤ áæ œ )ed mode switch. ˇ$å @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ ä
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä h ê ( e äT µ¿ ° d ONLN d \ è h · )o see this a bit mor uÄ ° d ONLN d \ ‚ h )S e clearly /¿ ° d ONLN d \ hb )$, suppose that you ar õ ° d ONLN d 3 \b h )\'e writing a native PowerPC application . ° d ONLN d Z i ä u ‰ ( r äthat calls the Contr R` ° d ONLN d n i ‰ u# )Z
ol Manager pr $¿ ° d ONLN d { i# u@ )?ocedur ˜ ° d ONLN d Å i? uF ) e ,
)Eepeatedly while . ° d ONLN d É ä è\ ( å ä/the user holds down the mouse button in a contr R` ° d ONLN d1 É\ èj )“ol. R` ° d ONLN d5 Éj è≤ ) TrackControl R` ° d ONLN dA É≤ èÙ )H has no way of . ° d ONLN dP ê ä ú √ ( ô ä determining ∫† ° d ONLN d\ ê √ ú ı )9 in advance A† ° d ONLN dg ê ˆ ú )3 the instr ∂¿ ° d ONLN dp ê úP )$
chitectur $¿ ° d ONLN d ™ Ω ∂ · )) e of the $¿ ° d ONLN d ™ · ∂) )$ TrackControl $¿ ° d ONLN d ™) ∂5 )H pr ˜ ° d ONLN d ™4 ∂Q ) ocedur …Ä ° d ONLN d% ™Q ∂ß ) e, so you cannot kno …Ä ° d ONLN d9 ™ß ∂π )Vw w …Ä ° d ONLN d< ™π ∂ )hether your action ˇˇΔÚ ° d ONLN dO ∑ ä √ î ( ¿ äpr R` ° d ONLN dQ ∑ î √ ± )
ocedur $¿ ° d ONLN dW ∑ ± √ ‹ )
e and the ˇˇT÷ yñ ° d ONLN da ∑ ‹ √$ )+ TrackControl ˇˇΔÚ yñ ° d ONLN dm ∑$ √/ )H pr Ë ° d ONLN dp ∑0 √M ) ocedur ÂH ° d ONLN dv ∑L √\ ) e ar ~ö ° d ONLN dz ∑] √í ) e of the sam ”p ° d ONLN dÜ ∑í √≠ )5e instr Üb ° d ONLN dç ∑Æ √„ )
uction set ar ʶ ° d ONLN dö ∑„ √ )5 chitectur π ° d ONLN d£ ∑ √ ))e. π ° d ONLN d• ∑ √ ) . ° d ONLN d¶ ƒ ä – £ ( Õ äAs a r I@ ° d ONLN d¨ ƒ § –D )&esult, you must explicitly indicate th
Ä ° d ONLN d“ ƒE –` )°e instr n‡ ° d ONLN dŸ ƒ` –ñ )
uction set ar e‡ ° d ONLN dÊ ƒñ –º )6 chitectur † ° d ONLN dÔ ƒΩ –… )'e o Ÿ¿ ° d ONLN dÚ ƒ… – ) f any callback ° d ONLN d — ä › ç ( ⁄ är E ° d ONLN d — é ›  )outines whose addr e` ° d ONLN d —  ›Ö )W$esses you pass to the system softwar † ° d ONLN d8 —Ü ›ç )°e.
H 4 H ä
ˇ·ˇ‚7^
ˇˇ‹. ˇ◊ ° d ONLN d; Û ä ( ˛ äRoutine Descriptors ˇˇˇˇˇˇ €r ( ˛1
° d ONLN dP ä ê ( äY @Ä ° d ONLN dQ ê Ã )ou indicate th ° d ONLN d_ Õ Ë )=e instr l` ° d ONLN df Ë )
uction set ar c` ° d ONLN ds D )6 chitectur ° d ONLN d| EQ )'e o ◊@ ° d ONLN d Qê ) f a particular r ‚ ° d ONLN dè êƒ )? outine by cr p` ° d ONLN dõ ≈Í )5 eating a ≈@ ° d ONLN d§ Í
)%routine ° d ONLN d¨ ä" ∏ ( ä
descriptor ñ ° d ONLN d∂ ∏" · ). for that r Ì@ ° d ONLN d¡ ·" )) outine. Her † ° d ONLN dÃ"@ )3 e is the str ∫ ° d ONLN dÿ@"W ),uctur ?‡ ° d ONLN d›X"v )e of a r ‡ ° d ONLN dÂv"¡ ) outine descriptor 7 ° d ONLN dˆ¡"√ )K. . ° d ONLN d¯* H6 ‰ (3 Hstruct RoutineDescriptor { ° d ONLN d7 ZC Æ +
unsigned short ° d ONLN d)7 ÿC8 )~goMixedModeTrap; ° d ONLN d?7DC¬ )l/*mixed-mode A-trap*/ ° d ONLN dVD ZP r (M Zchar ° d ONLN daD ÿP )~version; ° d ONLN doDDP¯ )l /*routine descriptor version*/ ° d ONLN dèQ Z] ú (Z Z RDFlagsType ° d ONLN d°Q ÿ]b )~routineDescriptorFlags; ° d ONLN d«^DjÏ +l
/*routine descriptor flags*/ ° d ONLN dÂk Zw ® (t Z
unsigned long ° d ONLN d˘k ÿw )~
reserved1; ° d ONLN d kDwå )l /*reserved*/ ° d ONLN dx ZÑ ® (Å Z
unsigned char ° d ONLN d+x ÿÑ )~
reserved2; ° d ONLN d;xDÑå )l /*reserved*/ ° d ONLN dIÖ Zë ® (é Z
unsigned char ° d ONLN d]Ö ÿë& )~
selectorInfo; ° d ONLN dpÖDë‘ )l/*selector information*/ ° d ONLN däí Zû x (õ Zshort ° d ONLN dñí ÿû& )~
RoutineRecord ° d ONLN dfiü ÿ´D )~routineRecords[1]; ° d ONLN dÛüD´Ê )l/*the individual routines*/ ° d ONLN d¨ H∏ T (µ H}; ° d ONLN dπ H≈z *
3typedef struct RoutineDescriptor RoutineDescriptor; ˇˇΩï . ° d ONLN dFÕ äŸ ë +BA G@ ° d ONLN dGÕ íŸ Â )s you can see, the fi ?È ° d ONLN d\Õ ÊŸ ˘ )Trst fi ¸> ° d ONLN dbÕ ˘Ÿ )
eld of a r ° d ONLN dlÕ Ÿµ )'#outine descriptor is an executable G¶ ° d ONLN dèÕµŸ– )ï680x0 ≠€ ° d ONLN dïÕ–Ÿ‰ )instr ≈õ ° d ONLN döÕ‰Ÿ ) uction that ° d ONLN d¶⁄ äÊ" („ ä invokes the Mixed Mode Manager Ÿ ° d ONLN dƒ⁄!Ê )ó5. When the Mixed Mode Manager is called, it inspects . ° d ONLN d˘Á äÛ † ( äthe r R` ° d ONLN d˛Á †Û ” )
emaining fi R` ° d ONLN d Á ”Û )3
elds of the r $¿ ° d ONLN dÁ Û≠ )6$outine descriptor—in particular the $¿ ° d ONLN d:Á≠Û )§routineRecords $¿ ° d ONLN dHÁÛ )T ° d ONLN dIÙ ä ë (˝ äfi ° d ONLN dKÙ ë ` )+eld—to determine whether a mode switch is r R` ° d ONLN dvÙ` w )œequir $¿ ° d ONLN d{Ùw õ )ed. The $¿ ° d ONLN dÉÙõ Ô )$routineRecords $¿ ° d ONLN dëÙÔ ¯ )T fi $¿ ° d ONLN dîÙ¯ ) eld is . ° d ONLN dõ ä
º (
ä an array of ° d ONLN dß Ω
)3routine records, ≥¿ ° d ONLN d∑
ø )G+ each element of which describes a single r Ä ° d ONLN d‚¿
˝ )ºoutine. In the ° d ONLN dÒ ä ( ä simplest case, the array of r ‡ ° d ONLN d% )youtine r ã@ ° d ONLN d%7 )"ecor ˇ† ° d ONLN d7» )!ds contains a single element. Her çÄ ° d ONLN d;…ı )í e is the str 7‡ ° d ONLN dGˆ
)-uctur Ω¿ ° d ONLN dL
)e ° d ONLN dN ä' † ($ äof a r ` ° d ONLN dT °' √ )outine r ï¿ ° d ONLN d\ √' ’ )"ecor
° d ONLN d` ÷' ‹ )d %‡ ° d ONLN da ‹' fi ). . ° d ONLN dc/ H; Ã (8 Hstruct RoutineRecord { ° d ONLN d{< ZH ¢ +
ProcInfoType ° d ONLN dé< ÿH )~ procInfo; ° d ONLN dù<DHŒ )l/*calling conventions*/ ° d ONLN d∂I ZU ® (R Z
unsigned char ° d ONLN d I ÿU )~
reserved1; ° d ONLN d⁄IDUå )l /*reserved*/ ° d ONLN dËV Zb Ñ (_ ZISAType ° d ONLN dˆV ÿb )~ISA; ° d ONLN d VDb )l /*instruction set architecture*/ ° d ONLN d "c Zo ∫ (l ZRoutineFlagsType ° d ONLN d 9c ÿo& )~
routineFlags; ° d ONLN d LcDo‡ )l/*flags for each routine*/ ° d ONLN d hp Z| Ñ (y ZProcPtr ° d ONLN d vp ÿ|2 )~procDescriptor; ° d ONLN d ãpD|Ê )l/*the thing we're calling*/ ° d ONLN d ®} Zâ ® (Ü Z
unsigned long ° d ONLN d º} ÿâ )~
reserved2; ° d ONLN d Ã}Dâå )l /*reserved*/ ° d ONLN d ⁄ä Zñ ® (ì Z
unsigned long ° d ONLN d Óä ÿñ )~ selector; ° d ONLN d ˝äDñ
)l!/*selector for dispatched calls*/ ° d ONLN d
ó H£ T († H}; ° d ONLN d
"§ H∞J *
+typedef struct RoutineRecord RoutineRecord; ° d ONLN d
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-16
)B
Mixed Mode 4 ^ *¿¯
. ° d ONLN d \ l h r ( e lT ° d ONLN d \ r h Œ )he most important fi ° d ONLN d \ Œ h ˙ )\ elds in a r R` ° d ONLN d \ ˙ h ),outine r $¿ ° d ONLN d ( \ h. )"ecor ˜ ° d ONLN d , \- h? )d ar …Ä ° d ONLN d 0 \? hX )e the ,
Courier …Ä ° d ONLN d 6 \X hà )procInfo …Ä ° d ONLN d > \à hë )0 fi …Ä ° d ONLN d A \ë h« ) eld and the …Ä ° d ONLN d M \« hŸ )6ISA <‡ ° d ONLN d P \Ÿ h‚ ) fi <‡ ° d ONLN d S \‚ hˆ ) eld. ° d ONLN d X i l u Ä ( r lThe ° d ONLN d \ i Ä u í )ISA Û` ° d ONLN d _ i ë u ö ) fi Û` ° d ONLN d b i ö u ˆ ) eld encodes the instr fl` ° d ONLN d w i ˆ u, )\
uction set ar ±¿ ° d ONLN d Ñ i, uU )6 chitectur Ñ ° d ONLN d ç iU u} ))
e of the r VÄ ° d ONLN d ó i} uÔ )(outine being described. It . ° d ONLN d ≤ v l Ç@ ( l/must always contain one of these two constants: . ° d ONLN d ‚ ç l ô ê *enum { ° d ONLN d Í õ ~ ß Æ +kM68kISA ° d ONLN d ¯ õ Í ß8 )l
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä h ê ( e äY @Ä ° d ONLN d \ ê h ∏ ) ou can cr 4 ° d ONLN d
\ ∏ h ◊ )(eate a r Œ† ° d ONLN d \ ◊ h ) =outine descriptor by calling the Mixed Mode Manager function ,
Courier . ° d ONLN d O i ä u ( r äNewRoutineDescriptor ¬† ° d ONLN d c i u< )w, as shown in ¬† ° d ONLN d q i< ul ); Listing 1-1 ¬† ° d ONLN d | il uo )0.
ò H † 4 ô H † " ô H_
ˇ·ˇ‚7^
. ° d ONLN d ~ é ä ô ∂ ( ñ ä Listing 1-1 ° d ONLN d ä é Œ ô? )D Creating a routine descriptor
ctionProc; ° d ONLN d » ∂ ä ¬ fi ( ø ämyActionProc = ° d ONLN d ÷ ∂ fi ¬‘ )T) NewRoutineDescriptor((ProcPtr)MyAction, ° d ONLN d ƒb –˛ +ÑuppControlActionProcInfo, ° d ONLN d3 “b fiº *GetCurrentISA() ° d ONLN dB “º fi» )Z); ° d ONLN dE Í ä ˆ ú ( Û äHer R` ° d ONLN dH Í ú ˆ ¶ )e, R` ° d ONLN dK Í ¶ ˆ ÷ )
MyAction R` ° d ONLN dS Í ÷ ˆ
)0 is the addr $¿ ° d ONLN d_ Í
ˆP )4ess of your contr ˜ ° d ONLN dp ÍO ˆÇ )E ol action pr …Ä ° d ONLN d| ÍÇ ˆü )3ocedur õ‡ ° d ONLN dÇ Íü ˆπ ) e and õ‡ ° d ONLN dà Íπ ˆ )
GetCurrentISA @ ° d ONLN dï Í ˆ )N . ° d ONLN dó ˜ ä Ê ( äis a C language macr n` ° d ONLN d´ ˜ Ê )\o that r ˇ ° d ONLN d≥ ˜F ) eturns the curr Ä ° d ONLN d¬ ˜Gk )B ent instr î† ° d ONLN dÀ ˜k° )$
uction set ar ㆠ° d ONLN dÿ ˜°« )6 chitectur @` ° d ONLN d· ˜»Ó )'e. When . ° d ONLN dÈ ä (
ä executed in the PowerPC envir R` ° d ONLN dJ )â onment, the R` ° d ONLN dJ¬ )7NewRoutineDescriptor R` ° d ONLN d&¬Ú )x function cr $¿ ° d ONLN d2Ú )0eates . ° d ONLN d9 ä ï ( äa r ≈ ° d ONLN d< ï i ) 0outine descriptor in your application heap and r _‡ ° d ONLN dlj Æ )’eturns the addr M‡ ° d ONLN d{Æ ‡ )D
ess of that r ˆ ° d ONLN dà‡ ˛ )2outine . ° d ONLN dè ä* ∏ (' ä
descriptor ¬† ° d ONLN dô ∑*S )-". When executed in the 680x0 envir ï ° d ONLN dª S*ä )ú onment, the ï ° d ONLN d« ä* )7NewRoutineDescriptor ï ° d ONLN d€ * )x . ° d ONLN d‹+ ä7 ÷ (4 äfunction simply r Δ@ ° d ONLN dÌ+ ÷7 )L eturns its fi N‡ ° d ONLN d˙+7C )2
rst parameter Ä ° d ONLN d+C7è );. Notice that the r ∂ ° d ONLN d+è7™ )Lesult r 3Ä ° d ONLN d!+´7› ) eturned by . ° d ONLN d-8 äD ú (A äthe ° d ONLN d18 úD )NewRoutineDescriptor ° d ONLN dE8Dh )x function is of type ° d ONLN dZ8hD» )TUniversalProcPtr ¬† ° d ONLN dj8«Dà )_. d@ ° d ONLN dl8ÃD‘ )A ◊† ° d ONLN dm8”D’ ) . ◊† ° d ONLN dn8’D )
universal ° d ONLN dxE äQ € (N äprocedure pointer k‡ ° d ONLN dâE ‹Q ˘ )R is defi É` ° d ONLN dëE ˘Qm ) ned to be either a 680x0 pr µ ° d ONLN d¨EmQã )tocedur L@ ° d ONLN d≤EåQ˛ ) e pointer or a pointer to a ° d ONLN dŒR ä^ ç ([ är E ° d ONLN dœR é^ Ÿ )outine descriptor d@ ° d ONLN d‡R Ÿ^= )K, essentially as follows: . ° d ONLN d˙i Hu Í (r H#if !USESROUTINEDESCRIPTORS ° d ONLN dw HÉí *7typedef ProcPtr UniversalProcPtr, *UniversalProcHandle; ° d ONLN dNÖ Hë f *#else ° d ONLN dTì Hü⁄ *Ctypedef RoutineDescriptor *UniversalProcPtr, **UniversalProcHandle; ° d ONLN dò° H≠ l *#endif . ° d ONLN düπ ä≈ +B!Once you’ve executed the code in g@ ° d ONLN d¿π!≈O )ó Listing 1-1 Ä ° d ONLN dÀπP≈_ )/ (pr ¢Ä ° d ONLN dœπ_≈ )(obably at application launch time), you . ° d ONLN d˜Δ ä“ » (œ äcan later call ° d ONLN dΔ »“ )> TrackControl ° d ONLN dΔ“= )H like this: ° d ONLN d › äÈD (Ê ä TrackControl(myControl, myPoint ° d ONLN d=›DÈû )∫, myActionProc) ° d ONLN dL›ûȧ )Z; ° d ONLN dNı äΔ (˛ äFIf your application is a PowerPC application, the value passed in the ° d ONLN dîıΔ (˛Δ gActionProc ° d ONLN düı
)B . ° d ONLN d† ä ˙ ( äparameter is not the addr ôÄ ° d ONLN dπ ˙S )pess of your action pr M‡ ° d ONLN dŒTr )Zocedur  ° d ONLN d‘r ) e itself, but the addr G` ° d ONLN dÍÀˆ )Y ess of the . ° d ONLN dı ä é ( är R` ° d ONLN dˆ é ‰ )outine descriptor cr $¿ ° d ONLN d
‰ )V eated in $¿ ° d ONLN d ; )' Listing 1-1 $¿ ° d ONLN d ;Ø )0. When a 680x0 version of $¿ ° d ONLN d8ؘ )t TrackControl $¿ ° d ONLN dD˜˘ )H . ° d ONLN dE ä( (% äexecutes your action pr #† ° d ONLN d\ Ò( )gocedur ∫‡ ° d ONLN db († ) #e, it begins by executing the instr –¿ ° d ONLN dÖ †( )ëuction contained in the ° d ONLN dù) ä5 ê (2 äfi å¿ ° d ONLN dü) ê5 £ )rst fi ãÄ ° d ONLN d•) §5 ” ) eld of the r E ° d ONLN d±) ‘5 )0outine descriptor d@ ° d ONLN d¬) 5N )K . That instr 0Ä ° d ONLN dŒ)O5 )0%uction invokes the Mixed Mode Manager ÚÄ ° d ONLN dÛ)5 )µ, ˇˇï@ . ° d ONLN dı6 äB ı (? äwhich inspects the instr +¿ ° d ONLN d
6 ˆB+ )l
uction set ar († ° d ONLN d6+BT )5 chitectur ˚ ° d ONLN d#6SBó )(e of the action r "` ° d ONLN d46òB )Eoutine (contained in the ˇ˛ø¿ w` ° d ONLN dM6B )kISA ˇˇï@ Í¿ ° d ONLN dP6B ) ˇ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-18
)B
Mixed Mode 4 ^ *¿¯
° d ONLN d \ l h r ( e lfi å¿ ° d ONLN d \ r h ° ) eld of the r F@ ° d ONLN d \ ¢ h ƒ )0outine r Õ† ° d ONLN d \ ƒ h ÷ )"ecor B ° d ONLN d \ ◊ h- )d contained in the r RÄ ° d ONLN d . \- h≤ )V!outine descriptor). If that instr £@ ° d ONLN d O \≤ hfl )Ö uction set . ° d ONLN d Z i l u v ( r lar R` ° d ONLN d \ i v u ü )
chitectur $¿ ° d ONLN d e i ü u ¥ ))e dif ˜ ° d ONLN d j i ≥ u Œ )fers fr …Ä ° d ONLN d q i Œ u ) om the instr µÄ ° d ONLN d } i u: )6
uction set ar ᇠ° d ONLN d ä i: uc )6 chitectur Z@ ° d ONLN d ì ic uá )) e of the ,
Courier Z@ ° d ONLN d ú iá uœ )$ TrackControl Z@ ° d ONLN d ® iœ u’ )H r ,† ° d ONLN d ™ i’ uˆ )outine, . ° d ONLN d ≤ v l Çπ ( lHthe Mixed Mode Manager causes a mode switch. Otherwise, if the two instr GÄ ° d ONLN d ˙ v∫ ÇÁ ( ∫ uction set ° d ONLN d É l è t ( å lar E ° d ONLN d É u è õ ) chitectur ˘¿ ° d ONLN d É õ è Ø )&es ar E` ° d ONLN d É ∞ èŒ )?e identical, the Mixed Mode Manager simply executes the action ° d ONLN dT ê l ú u ( ô lpr G ° d ONLN dV ê v ú î )
ocedur fi` ° d ONLN d\ ê î ú ) e without switching modes. ° d ONLN dw ¢ l Æ ˛ ( ´ l"In short, you solve the general pr rÄ ° d ONLN dô ¢ ˛ Æa )íoblem of indicating a r =` ° d ONLN d∞ ¢b ÆÅ )doutine’ G ° d ONLN d∑ ¢Å Æõ ) s instr ¿ ° d ONLN dæ ¢ú Æ“ )
uction set ar ¿ ° d ONLN dÀ ¢“ Æfl )6chi <¿ ° d ONLN dŒ ¢fl Æ‚ )
- ° d ONLN d– Ø l ª Ö ( ∏ ltectur
¿ ° d ONLN d÷ Ø Ü ª í )e b ‹ ° d ONLN dŸ Ø í ª ¢ ) y cr ` ° d ONLN d› Ø £ ª ƒ )eating r ∫@ ° d ONLN dÂ Ø ƒ ªx )!(outine descriptors and by using the addr æ† ° d ONLN d
Øx ª∫ )¥esses of those r ß ° d ONLN d Ø∫ ªÿ )Boutine ° d ONLN d$ º l » ∂ ( ≈ ldescriptors wher @ ° d ONLN d4 º ∑ »* )Ke you would have used pr m@ ° d ONLN dL º* »H )socedur Ä ° d ONLN dR ºI »∏ ) e pointers in the 680x0 pr B ° d ONLN dl º∏ »Ó )o
uction set ar ↠° d ONLN dg „Ä Ô¶ )6 chitectur >` ° d ONLN dp „ß Ô± )'e f €‡ ° d ONLN ds „± Ô¥ )
r †‡ ° d ONLN dt „µ Ô… )om t ¨¿ ° d ONLN dx „… Ôfl )hat o ∂ ° d ONLN d} „fl Ôı )f the ° d ONLN dÉ l ¸ o ( ˘ lr E ° d ONLN dÑ p ¸ • ) outine. Ther ° d ONLN dê ¶ ¸ ∂ )6e ar ¿ ° d ONLN dî ∂ ¸Ñ ).e quite a number of cases in which you pass pr =¿ ° d ONLN d¬ Ñ ¸¢ )Œocedur ’ ° d ONLN d» ¢ ¸Î ) e pointers to the ° d ONLN d⁄ ˝ l Æ ( lsystem softwar M‡ ° d ONLN dË ˝ Ø ˘ )Ce and which ther y` ° d ONLN d¯ ˝ ˘
)Jefor —` ° d ONLN d¸ ˝
)e r ‡ ° d ONLN dˇ ˝ , ) equir ˜@ ° d ONLN d ˝, Ú ).e you to use the techniques illustrated above ° d ONLN d2
l î ( l for Contr !@ ° d ONLN d;
ï Ò ))ol Manager action pr : ° d ONLN dO
Ò )\ocedur —` ° d ONLN dU
x ) es. Some of the typical r ´@ ° d ONLN dn
x⁄ )ioutines you need to cr £‡ ° d ONLN dÑ
⁄Ó )beate ° d ONLN dâ l# o ( lr E ° d ONLN dä p# Ú ) outine descriptors for include ,
° d ONLN d´* x6 Å ) gr ‘ ° d ONLN d≠* Å6 “ ) ow-zone functions
° d ONLN dø? lF q (E ln
° d ONLN d¡< xH é ) contr >Ä ° d ONLN dΔ< èH ¡ ) ol action pr E` ° d ONLN d“< ¡H fl )2ocedur ‹† ° d ONLN dÿ< flH Ë ) es
° d ONLN d€Q lX q (W ln
° d ONLN d›N xZ ò ) event fi Z ° d ONLN dÂN ôZ ” )!lter functions
° d ONLN dÙc lj q (i ln
° d ONLN dˆ` xl ã ) VBL ë@ ° d ONLN d˘` ãl £ ) tasks
° d ONLN d u l| q ({ ln
° d ONLN dr x~ ~ ) T ° d ONLN dr ~~ — )ime Manager tasks
° d ONLN dá lé q (ç ln
° d ONLN dÑ xê í ) trap p 9@ ° d ONLN d Ñ ìê Æ )atches
° d ONLN d$ô l† q (ü ln
° d ONLN d&ñ x¢ ∞ ) completion r §Ä ° d ONLN d2ñ ∞¢ – )8outines ° d ONLN d:ß l≥ Æ (∞ lThe interface fi é† ° d ONLN dJß Æ≥K )B"les for the PowerPC system softwar ó‡ ° d ONLN dlßK≥Ö )ù
e have been r ‘ ° d ONLN dyßÖ≥— ):evised to change . ° d ONLN d㥠l¿ Ä (Ω lall r R` ° d ONLN dê¥ Ä¿ í )efer $¿ ° d ONLN dî¥ í¿ ˛ )ences to parameters or fi $¿ ° d ONLN d≠¥ ˛¿5 )l
elds of type $¿ ° d ONLN d∫¥5¿_ )7ProcPtr $¿ ° d ONLN d¡¥_¿p )* to r ˜ ° d ONLN dΔ¥o¿Å )efer …Ä ° d ONLN d ¥Å¿º )ences of type ° d ONLN dÿ¡ lÕ Ã ( lUniversalProcPtr ¬† ° d ONLN dË¡ ÀÕ7 )_. In addition, these new . ¬† ° d ONLN d¡7Õí )luniversal interface f G¿ ° d ONLN d¡íÕ¢ )[iles . _¿ ° d ONLN d¡¢Õ— ) contain pr 2 ° d ONLN d%¡—ÕÓ )/ocedur Ä ° d ONLN d+¡ÓÕı ) e . ° d ONLN d-Œ l⁄ ¥ (◊ linformation defi ≠Ä ° d ONLN d=Œ ¥⁄# )Hnitions for all the standar ±Ä ° d ONLN dXŒ#⁄| )od kinds of callback r ≈@ ° d ONLN dmŒ|⁄¥ )Y outines. Mor Ù` ° d ONLN dyŒ¥⁄à )8eover ÿ† ° d ONLN d~ŒÃ⁄· ), the ° d ONLN dÑ€ lÁ Δ (‰ luniversal interface fi † ° d ONLN dö€ «Á Ê )[les defi |¿ ° d ONLN d¢€ ÊÁ ) ne new r Œ¿ ° d ONLN d™€ Áà )&,outines that you can use in place of the mor ¿ ° d ONLN d÷€ÕÁ˜ )¡
e general . ° d ONLN d‡Ë lÙ ¨ (Ò lcode shown in ° d ONLN dÓË ¨Ù )@Listing 1-1 on page ° d ONLN dËÙ )V1- ° d ONLN dË Ù ) 17 ° d ONLN dËÙõ )
. For example, the interface fi ° d ONLN d%ËõÙ¶ )Üle ° d ONLN d(˶ق )
Controls.h ° d ONLN d2Ë‚Ù‰ )< ° d ONLN d3ı l ∑ (˛ lcontains the defi ° d ONLN dDı ∑ ˛ )Knition shown in ° d ONLN dTı ˛. )G Listing 1-2 ° d ONLN d_ı.Q )0 for the ° d ONLN dhıQ… )#NewControlActionProc ° d ONLN d|ı…Ú )x
° d ONLN d«4 l@b (= l)typedef UniversalProcPtr ControlActionUPP ° d ONLN d4b@h )ˆ; ° d ONLN dÚB lN r (K l# ° d ONLN dÛB rN\ )'define NewControlActionProc(userRoutine ° d ONLN dB\Nn )Í) \ ° d ONLN d P ~\ Ñ (Y ~( ° d ONLN d P Ñ\Ê );ControlActionUPP) NewRoutineDescriptor((ProcPtr)userRoutine ° d ONLN d[PÊ\¯ (YÊ, \ ° d ONLN d`^ ~j Ñ (g ~u ° d ONLN da^ Ñjz ))ppControlActionProcInfo, GetCurrentISA()) . ° d ONLN dãv lÇ ® ( lBecause this r ·Ä ° d ONLN dôv ®Ç · )<
outine is defi ;` ° d ONLN dßv ‚Çc ): ned in the universal header fi —¿ ° d ONLN d≈vcÇù )Åles, you can r ” ° d ONLN d”vùÇÓ ):eplace the code in ° d ONLN dÊÉ lè ö (å l Listing 1-1 @ ° d ONLN dÒÉ õè+ )/ with the simpler code shown in ¢ ° d ONLN d É+èY )ê Listing 1-3 B@ ° d ONLN d ÉZè\ )/. ˇ!f @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ ä The PowerPC Native Environment
° d ONLN dG œ ä € ê ( ÿ äY @Ä ° d ONLN dH œ ê € Ë )ou do not need to cr ≈ ° d ONLN d\ œ Ë € )Xeate r fl¿ ° d ONLN db œ €e )outine descriptors for r z` ° d ONLN dz œf €• )foutines that ar ‡ ° d ONLN dâ œ¶ €… )@ e called ° d ONLN dí € ä Á ( ‰ ä only by your application. Mor : ° d ONLN dØ € Á? )Ö e generally Æ@ ° d ONLN d∫ €> ÁΔ )/!, if you know for certain that a ° d ONLN d€ Á ä Û ç ( är E ° d ONLN d‹ Á é ÛG )*outine is always called by code of the sam x@ ° d ONLN d ÁG Ûb )πe instr Ÿ† ° d ONLN d
Áb Ûò )
uction set ar –† ° d ONLN d Áò Ûæ )6 chitectur Ö` ° d ONLN d# Áø ÛΔ )'e, œ ° d ONLN d% ÁΔ Û» ) ° d ONLN d& Û ä ˇ Ø ( ¸ äyou can Õ` ° d ONLN d. Û Ø ˇ „ )% and should I† ° d ONLN d9 Û ‰ ˇ3 )5continue to use pr ⁄` ° d ONLN dK Û3 ˇQ )Oocedur q† ° d ONLN dQ ÛR ˇÆ ) e pointers instead of ° d ONLN dg ˇ ä ø ( ä universal pr ‡ ° d ONLN ds ˇ ¿ fi )6ocedur ß ° d ONLN dy ˇ fi A ) e pointers. If, however ¿ ° d ONLN dê ˇA I )c, t _ ° d ONLN dì ˇI k )he addr v† ° d ONLN dö ˇk ª )"ess of one of your ° d ONLN d≠ ä … ( äapplication’s r Ä ° d ONLN dº …O )? outines might be passed to a T ˇ ° d ONLN d⁄ Nà )Öoolbox or Operating System ° d ONLN dı ä# ç ( är E ° d ONLN dˆ é# )outine, you should make sur ÿ ° d ONLN d #; )~ e to use a r ,` ° d ONLN d <#á )0outine descriptor K† ° d ONLN d.á#â )K. ,
° d ONLN dIN äZ (W ä!The technique described in the pr e‡ ° d ONLN djN Zç )îevious section for using r n@ ° d ONLN dÑNçZ )o!outine descriptors is by far the ° d ONLN d•[ äg; (d ä(simplest and easiest to implement: any r Q@ ° d ONLN dÕ[<g )≤.outine descriptors needed by an application ar ¥† ° d ONLN d˚[ g )Õe ° d ONLN d˝h ätfl (q äOallocated in the application heap at application launch time. The descriptors r ÂÄ ° d ONLN dLhflt¸ (qflemain ° d ONLN dRu äÅ® (~ äCallocated until the application terminates, at which time the entir x¿ ° d ONLN dïu®Å (~®e application heap is ° d ONLN d´Ç äé ç (ã är E ° d ONLN d¨Ç éé ‡ )eclaimed by the Pr K¿ ° d ONLN dæÇ ‡é! )R
ocess Manager …¿ ° d ONLN dÀÇ é% )@. k` ° d ONLN dÕÇ%é> )As a r 4† ° d ONLN d”Ç?é ))esult, you don’t have to dispose of any r Ä ° d ONLN d¸Çé )±outine ° d ONLN dè äõ Δ (ò ädescriptors cr åÄ ° d ONLN dè Δõ )<eated in this way ª ° d ONLN d"èõ )J. ° d ONLN d$° ä≠É (™ ä8If, in some case, you know that you won’t be needing a r ‘¿ ° d ONLN d\°É≠ˆ )˘outine descriptor any mor ` ° d ONLN du°˜≠˛ )te ° d ONLN dwÆ ä∫¯ (∑ äVduring the execution of your application, you can explicitly dispose of it by calling . ° d ONLN dŒª ä« ú *
the ° d ONLN d“ª ú«, )DisposeRoutineDescriptor ° d ONLN dͪ,« )ê3 function. This is most useful when you allocate a . ° d ONLN d » ä‘ ç (— är E ° d ONLN d » é‘B )(outine descriptor for temporary use only Z ° d ONLN dF»A‘ )≥-. For example, you might call some code that ° d ONLN ds’ ä· ◊ (fi äuses a callback pr Ÿ‡ ° d ONLN dÖ’ ◊· ı )Mocedur q ° d ONLN dã’ ˆ·9 ) e only very infr =` ° d ONLN dõ’:·` )Dequently ‡` ° d ONLN d£’_·ˆ )%%. In that case you can allocate the r Ä ° d ONLN d»’˜· )òoutine ° d ONLN dœ‚ äÓP (Î ä-descriptor when the code is called and then r ≤¿ ° d ONLN d¸‚PÓ⁄ )Δ elease it when the code is done. ° d ONLN d Ù ä ® (˝ äFinally
° d ONLN d$Ù ® ⁄ ) , you can cr è† ° d ONLN d0Ù ⁄ ˘ )2eate a r *@ ° d ONLN d8Ù ˙ ) Coutine descriptor on the stack if you intend to use it only within . ° d ONLN d{ ä
π (
ä a single pr R` ° d ONLN dÜ π
÷ )/ocedur $¿ ° d ONLN då ÷
ä ) %e. The Mixed Mode Manager interface fi $¿ ° d ONLN d≤ä
ï )¥le $¿ ° d ONLN dµï
◊ ) MixedMode.h $¿ ° d ONLN d¿◊
Î )B defi $¿ ° d ONLN d≈Î
)
nes the C ° d ONLN dœ ä À ( ä
language macr R` ° d ONLN d‹ À “ )Ao R` ° d ONLN dfi “b )BUILD_ROUTINE_DESCRIPTOR R` ° d ONLN dˆbı )ê" that you can use for this purpose R` ° d ONLN dı )ì, as . ° d ONLN d ä'
($ ä!well as for initializing static r ∞@ ° d ONLN d>
'd )Äoutine descriptors. F Y ° d ONLN dSe'£ )[or details, see Δ‡ ° d ONLN dc£' )>“Using Static Routine ° d ONLN dy( ä4 Í (1 äDescriptors” on page öÄ ° d ONLN dé( Í4 ¸ )`2-22 Ó` ° d ONLN dí( ¸4„ )2 in the chapter “Mixed Mode Manager” in this book.
° d ONLN dÊw äÉ ë (Ä äA ∫† ° d ONLN dÁw ëÉ ì ) :† ° d ONLN dËw îÉ ˘ )run-time environment ïÄ ° d ONLN d¸w ˘É )e@ is a set of conventions that determine how code is loaded into ° d ONLN d <Ñ äê Ø (ç ämemory Õ ° d ONLN d BÑ Æê … )$, wher Ñ ° d ONLN d HÑ ê ) e data is stor ° d ONLN d VÑê` )8ed and how it is addr H ° d ONLN d kÑ`ê˛ )^$essed, and how functions call other ° d ONLN d èë äù (ö ä functions and system softwar Ü@ ° d ONLN d ´ë ù )Çe r î‡ ° d ONLN d ÆëùS ) outines. The r .† ° d ONLN d ºëTùê )=
un-time envir í ° d ONLN d …ëêùÛ )<onment available on a ° d ONLN d flû ä™ ¶ (ß äspecifi Ó ° d ONLN d Êû ¶™˚ ) Jc Macintosh computer is determined jointly by the Macintosh system softwar È` ° d ONLN d
0û˚™ (ß˚e ° d ONLN d
2´ ä∑Û (¥ äN(which manages the loading and scheduling of executable code) and your softwar Ú† ° d ONLN d
Ä´Û∑˙ (¥Ûe ˇ P @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-20
)B The PowerPC Native Environment 4 ^ *¿¯
° d ONLN d \ l hº ( e lGdevelopment system (which generates code to conform to the documented r Ç¿ ° d ONLN d G \º h· ( eºun-time ° d ONLN d O i l u ß ( r l
conventions). ° d ONLN d ] { l á É *The r ö` ° d ONLN d b { É á ø )
un-time envir ˝¿ ° d ONLN d o { ø áy )<(onment for native PowerPC code is signifi <Ä ° d ONLN d ò {z ᣠ)ª
cantly dif ‚` ° d ONLN d ¢ {£ áØ ))fer ƒ‡ ° d ONLN d • {Ø áΔ ) ent fr ; ° d ONLN d ´ {« áË )om the ° d ONLN d ≤ à l î o ( ë lr ^† ° d ONLN d ≥ à p î ¨ )
un-time envir ¬ ° d ONLN d ¿ à ¨ îc )<'onment for 680x0 code with which you ar `@ ° d ONLN d Á àd îu )∏e pr q ° d ONLN d Î àu î° )
obably alr ö† ° d ONLN d ı à° î€ ),
eady familiar •` ° d ONLN d à€ î‡ ):. ° d ONLN d ï l ° ƒ ( û lIn general, however @ ° d ONLN d ï ƒ ° )X, the PowerPC r z@ ° d ONLN d' ï °E )E
un-time envir ›† ° d ONLN d4 ïE °” )< onment is both simpler and mor '‡ ° d ONLN dR ï‘ °€ )èe ° d ONLN dT ¢ l Æ › ( ´ lpowerful than the 680x0 r ° d ONLN dm ¢ fi Æ )r
un-time envir Ä ° d ONLN d; ºà »— )=onment, all discr ‡ ° d ONLN dL º— »‡ )Iete ° d ONLN dP … l ’{ ( “ l=collections of executable code—including applications, code r ‰‡ ° d ONLN dç …{ ’ì ( “{esour - ° d ONLN dí …î ’Ì )ces, extensions, and ° d ONLN dß ÷ l ‚ ÷ ( fl leven the system softwar 6 ° d ONLN dæ ÷ ◊ ‚ )k e itself—ar ≤` ° d ONLN d… ÷ ‚ )/e or 6Ä ° d ONLN dÕ ÷ ‚Ì ),ganized as fragments when loaded into memory F‡ ° d ONLN d˘ ÷Ï ‚Ò )’. ° d ONLN d˚ „ l Ô Ü ( Ï lAccor b@ ° d ONLN d „ Ü Ô ¢ )dingly "† ° d ONLN d „ ¢ Ô ) , all executable code shar ¡ ° d ONLN d „ ÔE )m es the benefi û ° d ONLN d- „F Ôâ )7ts that derive fr <¿ ° d ONLN d> „ä Ô¥ )D om the or û ° d ONLN dG „¥ Ô )*ganization of ° d ONLN dU l ¸ » ( ˘ lfragments, including ,
Zapf Dingbats
° d ONLN dj l
q *n
° d ONLN dl x ) $a uniform set of calling conventions
° d ONLN dë l q ( ln
° d ONLN dì x! √ ) the ability to stor a` ° d ONLN d¶ √!ß )K3e code called by many applications or other softwar n ° d ONLN dŸß!± )‰e i † ° d ONLN d‹±!π )
n ° d ONLN dfl! x- Ω (* ximport libraries
° d ONLN d6 l= q (< ln
° d ONLN dÚ3 x? ° ) a simplifi Ÿ ° d ONLN d¸3 °? Ó ))ed means of addr ∞@ ° d ONLN d 3 Ó?= )Messing global data
° d ONLN d H lO q (N ln
° d ONLN d!E xQ ) ?the ability to execute special initialization and termination r o‡ ° d ONLN d`EQÕ (Noutines when the ° d ONLN dqQ x]( (Z x'fragment is loaded into and unloaded fr :Ä ° d ONLN dòQ)]_ )± om memory ° d ONLN d¢b ln ‚ (k l This section describes the r 7‡ ° d ONLN dæb „n )w
un-time envir õ@ ° d ONLN dÀb nŸ )<)onment for applications and other softwar Z¿ ° d ONLN dÙb⁄n· )ªe ° d ONLN dˆo l{ › (x lexecuting on PowerPC pr Ä ° d ONLN d
o ›{ ˝ )qocessor „` ° d ONLN do ˝{⁄ ) 2-based Macintosh computers. It describes in detail
° d ONLN dGÖ lå q (ã ln
° d ONLN dIÇ xé ì ) the str ;` ° d ONLN dPÇ îé ´ ) uctur ¡@ ° d ONLN dUÇ ´é Í )e of fragments
° d ONLN ddó lû q (ù ln
° d ONLN dfî x† Æ ) how to addr “@ ° d ONLN dqî Ɔ )6ess global code and data
° d ONLN då¶ x≤ ã ) subr ¿ ° d ONLN dê¶ å≤ Ÿ )outine invocation
° d ONLN d¢ª l¬ q (¡ ln
° d ONLN d§∏ xƒ € ) PowerPC stack frames
° d ONLN dπÕ l‘ q (” ln
° d ONLN dª x÷ Ω ) import libraries
° d ONLN dÃfl lÊ q (Â ln
° d ONLN dŒ‹ xË ë ) the or ‡ ° d ONLN d‘‹ íË Û )ganization of memory
ı *¯ 4ˆ *¯
° d ONLN dȈ l˛ ã (¸ lIMPORT Ä ° d ONLN dÔˆ ã˛ õ ) ANT
ˇ·ˇ‚7^
° d ONLN dÛ l
“ (
lKeep in mind that the r L‡ ° d ONLN d
”
)g
un-time envir ∞@ ° d ONLN d
D )<
onment defi † ° d ONLN d"E
ì )6ned by the use of ° d ONLN d4
l Í ( l fragments might in the futur £‡ ° d ONLN dP
Íü )~(e be available on 680x0-based Macintosh ° d ONLN dx l%% (" l'computers (and not solely on PowerPC pr ‡ ° d ONLN dü%%E )πocessor I¿ ° d ONLN d¶F%ñ )!-based Macintosh ° d ONLN d∑% l1 œ (. lcomputers). The new r ^‡ ° d ONLN dÃ% –1 )d
un-time envir ¬@ ° d ONLN dŸ% 1ì )< onment based on fragments is ° d ONLN dˆ1 l= √ (: lintended to be as pr %Ä ° d ONLN d
1 ƒ=T )X ocessor independent as possible.
= ° d ONLN d+4Y<` )ïs
a *h¯ 4b *h¯ c lc¯
ˇ·ˇ‚7^
ˇˇ‹. ˇ◊ ° d ONLN d-R la ≠ (] l Fragments ˇˇˇˇˇˇ €r (]1
° d ONLN d8h lt ã (q lIn the r k‡ ° d ONLN d@h åt » )
un-time envir œ@ ° d ONLN dMh »t ¸ )< onment intr † ° d ONLN dXh ˝tB )5oduced in the fi Ä ° d ONLN dhhBt— )E!rst version of the system softwar œ‡ ° d ONLN dâh—tÁ )èe for ° d ONLN dèu lÅ ¢ (~ l
PowerPC pr z ° d ONLN dôu ¢Å ¬ )6ocessor fi ° d ONLN d†u ¬ÅÎ ) B-based Macintosh computers, the basic unit of executable code and ° d ONLN d‚Ç lé œ (ã lits associated data is a [ ° d ONLN d˚Ç –é ¸ )d fragment. Ñ¿ ° d ONLN dÇ ¸é ˛ ), ¶` ° d ONLN dÇ ˛éP )All fragments shar ’¿ ° d ONLN dÇPé )Re a number of fundamental ° d ONLN d1è lõ u (ò lpr G ° d ONLN d3è võ ¸ )
!operties, such as their basic str ¢¿ ° d ONLN dTè ¸õ )Üuctur († ° d ONLN dYèõ⁄ )-e and their method of accessing code or data ° d ONLN dÜú l®P (• l3contained in themselves or in other fragments. Ther À¿ ° d ONLN dπúP®` )‰e ar ⁄` ° d ONLN dΩú`®ê )
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä h ( e ä Fragments can be loosely dif é ° d ONLN d \ h )~fer pÄ ° d ONLN d \ h[ ) entiated into thr ®` ° d ONLN d 0 \[ hÓ )G!ee categories, based on how they ° d ONLN d R i ä u í ( r äar E ° d ONLN d T i ì u ± ) e used. ,
° d ONLN d_$ ñ0 ¶ ) An ò† ° d ONLN db$ ¶0 — ) extension w@ ° d ONLN dk$ “0 ),I is a fragment that extends the capabilities of some other fragment. For ° d ONLN d¥0 ñ<‡ (9 ñGexample, your application might use external code modules like menu defi ˇÄ ° d ONLN d¸0‡<¸ (9‡nition ° d ONLN d< ñH € (E ñfunctions, contr â¿ ° d ONLN d< €H ˆ )Eol defi Y¿ ° d ONLN d< ˜Hù ) &nition functions, or data-conversion fi ˝ ° d ONLN dA<ùHŒ )¶ lters. Unlik † ° d ONLN dM<œH˜ )2 e import ° d ONLN dVH ñT º (Q ñ
libraries, ,† ° d ONLN d`H ΩTı )'H extensions must be explicitly connected to your application during its ° d ONLN d®T ñ` ⁄ (] ñexecution. Ther •† ° d ONLN d∑T ⁄` Í )De ar ¥@ ° d ONLN dªT Í`˜ )=e two types of extensions: application extensions and system ° d ONLN d¯` ñl … (i ñ extensions. öÄ ° d ONLN d` …l Ÿ )3An ≥ ° d ONLN d` Ÿl; )application extension ≥‡ ° d ONLN d `;lË )b* is an extension that is used by a single ° d ONLN dFl ñx à (u ñ
application. ÿÄ ° d ONLN dSl Ãx ” )6A ° d ONLN dTl ‘x ÷ ) ì ° d ONLN dUl ÷x$ )system extension ò‡ ° d ONLN del$x )N6 is an extension that is used by the Operating System ° d ONLN dõx ñÑ‹ (Å ñNor by multiple applications; it is usually installed at system startup time fr ° d ONLN dÈx‹ÑÙ (Å‹om a . ° d ONLN dÓÑ ñê ö (ç ñr R` ° d ONLN dÔÑ öê ± )esour $¿ ° d ONLN dÙÑ ±ê fi ) ce of type ,
Courier $¿ ° d ONLN dˇÑ fiê )-'INIT' $¿ ° d ONLN dÑê )$, $¿ ° d ONLN dÑê+ )'DRVR' $¿ ° d ONLN d
)E, for example, is ° d ONLN d 8ı ä ö (˛ ästor 9‡ ° d ONLN d <ı õL )%ed in the ROM of a Macintosh computer h† ° d ONLN d aıLf )±. Othe !‡ ° d ONLN d gıg∫ )r import libraries a * ° d ONLN d {ı∫Ω )Sr Ô ° d ONLN d |ıΩ˛ )e typically stor ˛¿ ° d ONLN d åı˛ )Aed . ° d ONLN d è ä ú ( äin fi ° d ONLN d î ú Õ ) les of type ° d ONLN d † Õ Ò )1'shlb' ° d ONLN d ¶ Ò )$>. The fragment containing an application’s executable code is ° d ONLN d ‰ ä õ ( ästor R` ° d ONLN d Ë õm )/ed in the application’s data fork, which is a fi R` ° d ONLN d
‚N ™Z∂ ) Ble (possibly even the application’s data fork itself), not into a ° d ONLN d $Z äf ç (c är E ° d ONLN d %Z éf ¶ )esour ç@ ° d ONLN d *Z ¶f » )ce. Ther G‡ ° d ONLN d 2Z …f )#
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-22
)B The PowerPC Native Environment 4 ^ *¿¯
° d ONLN d \ l h º ( e lfor loading and pr 2¿ ° d ONLN d \ Ω h@ )Q eparing fragments. Fragment ¿@ ° d ONLN d . \@ hu )É preparation † ° d ONLN d 9 \v hŒ )6 consists mainly in r .Ä ° d ONLN d N \Œ hı )X esolving ° d ONLN d W i l uÄ ( r l;any imports in the fragment; the Code Fragment Manager sear ¿ ° d ONLN d í iÅ uı ( rÅches for another fragment ° d ONLN d ¨ v l Ç æ ( l(an import library) .‡ ° d ONLN d ø v ø ÇÒ )SD that exports the symbols imported by the fragment being loaded. Of ° d ONLN d É l è ñ ( å l
course, th y‡ ° d ONLN d
É ó è ‹ )+e import library y@ ° d ONLN d É › è™ )F. containing the code or data imported by the fi ≥` ° d ONLN dL É™ è‚ )Õ
rst fragment ° d ONLN dY ê l ú ( ô l(might itself contain imported symbols fr ™ ° d ONLN dÅ ê úV )≤
° d ONLN d# ≈ l Õ ã ( À lIMPORT Ä ° d ONLN d) ≈ ã Õ õ ) ANT
ˇ·ˇ‚7^
° d ONLN d- – l ‹ì ( Ÿ lAIn general, the Code Fragment Manager is called by the Operating ° d ONLN dn ‹ l Ë ù * System in r ͆ ° d ONLN dy ‹ ù Ë Ÿ )1esponse to a r =¿ ° d ONLN dá ‹ ⁄ Ë, )=equest to load som († ° d ONLN dô ‹- Ë8 )Se s Ø@ ° d ONLN dú ‹8 ËP ) pecifi ‡` ° d ONLN d¢ ‹P Ëî )c fragment (for ° d ONLN d≤ Ë l ÙT ( Ò l3example, when the user launches an application). Th Ú‡ ° d ONLN d ËT Ù¢ )Ëe import libraries ° d ONLN d¯ Ù l r ( ˝ lu á ° d ONLN d˘ Ù r Ÿ )sed by that fragment ar b` ° d ONLN d Ù Ÿ = )ge loaded automatically ˝ ° d ONLN d& Ù< ° )c, if the Code Fragment ° d ONLN d= l ≠ ( l
uses custom a ° d ONLN d$ ™0ú )>8pplication extensions. See the beginning of the chapter ° d ONLN dL0 l<L (9 l1“Code Fragment Manager” in this book for details. ,
° d ONLN d–æ là ˛ (» lThe Structure of Fragments ˇˇˇˇˇˇ ‘@ (»Ò1
° d ONLN dÏ“ lfi[ (€ l2Once a fragment has been loaded into memory and pr VÄ ° d ONLN d “[fin )Ôepar Á@ ° d ONLN d"“nfiı ) ed for execution, the code and ° d ONLN dAfl lÎ ∫ (Ë ldata it contains ar > ° d ONLN dTfl ªÎÙ )OJe available to itself and to any fragments that import parts of that code ° d ONLN dûÏ l¯` (ı l7and data. The code and data of a particular fragment ar §† ° d ONLN d’Ï`¯√ )Ùe loaded into separate F@ ° d ONLN dÏσ¯Ë )dsections Ȇ ° d ONLN dÙÏË¯Í )$ ° d ONLN dˆ˘ l { ( lor r - ° d ONLN d˙˘ | À )egions of memory † ° d ONLN d
˘ Àfl )O@. In general, the code and data sections of a loaded fragment ar î‡ ° d ONLN dJ˘flÊ (fle ° d ONLN dM l/ ( l)not contiguous with one another in memory º` ° d ONLN dv.‡ )¬+. Instead, the data section of a fragment i ≠¿ ° d ONLN d°·Á )≥s ° d ONLN d£ l n ( ll h` ° d ONLN d§ o Ú )Yoaded either into your application’s heap or into the system heap. The code section of a ° d ONLN d˝ l, () l#fragment is usually loaded elsewher ¶ ° d ONLN d ,C )† e in memory v† ° d ONLN d + C,\ )7. (See Ä ° d ONLN d 2 ],· ) “File Mapping” beginning on ° d ONLN d N- l9 É (6 lpage Z‡ ° d ONLN d S- Ñ9 ñ )1-53 Æ¿ ° d ONLN d W- ñ9¡ )G for details on the location of the code sections of a fragment.) Regar † ° d ONLN d û-¬9Ê (6¬ dless of ° d ONLN d ß: lF Ç (C lwher 7 ° d ONLN d ´: ÉF — )e it is loaded, ther “ ° d ONLN d ø: —FÀ )N9e is no segmentation within a code section of a fragment. ° d ONLN d ˘L lX8 (U l,Because every fragment contains both code an √@ ° d ONLN d
%L8XF )Ãd d z¿ ° d ONLN d
(LGXË )'ata sections, it follows that any code ° d ONLN d
OY le ˜ (b l executing in a fragment-based r [¿ ° d ONLN d
nY ¯e4 )å
un-time envir ø ° d ONLN d
{Y4eË )<%onment—not just application code—can ° d ONLN d
†f lr
(o l&have global variables. (In the 680x0 r ˛Ä ° d ONLN d
Δf
rI )°
un-time envir a‡ ° d ONLN d
”fJrå )=onment, it’s dif 3Ä ° d ONLN d
„fçrì )Cfi @@ ° d ONLN d
Âfìrı )cult for some kinds of ° d ONLN d
¸s l< (| l1code to have global variables.) In addition, ther –¿ ° d ONLN d -s<fi )–)e is no practical limit on the size of a ° d ONLN d VÄ lå‰ (â lZfragment’s data section. By contrast, the total size of an application’s global variables ° d ONLN d ±ç lô ∫ *
in the 680x0 envir Æ` ° d ONLN d √ç ∫ô• )N2onment is 32 KB, unless your development system pr √† ° d ONLN d ıç•ô )Îovides special ° d ONLN d ö l¶ ˜ (£ l"capabilities to exceed that limit. ˇ$Ï @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ ä The PowerPC Native Environment
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä h √ ( e ä Fragments cr 4Ä ° d ONLN d \ ƒ h ):eated by the curr … ° d ONLN d \ h )J<ently available linkers contain one section of code and one ° d ONLN d Y i ä u: ( r ä+section of static data (although it’s theor ` ° d ONLN d Ñ i; uπ )± etically possible to have mor ˛ ° d ONLN d ° i∏ u
)}e than one of each ° d ONLN d ¥ v ä Ç “ ( ätype of section). ƒ† ° d ONLN d Δ v “ Ç Ÿ )HA ˇ@ ° d ONLN d « v Ÿ Ç
) fragment’s äÄ ° d ONLN d ” v ÇE )5 code section X¿ ° d ONLN d fl vF Çî )8 must contain pur ¥¿ ° d ONLN d vî Ç )N e executable code, that is, ° d ONLN d É ä èÑ ( å ä7code that is independent of the location in memory wher < ° d ONLN dC ÉÖ è— )˚e it is loaded. Pur
† ° d ONLN dV É“ è )Me code can be ° d ONLN dd ê ä ú “ ( ô äloaded anywher vÄ ° d ONLN dr ê “ ú Ÿ )He ¿ ° d ONLN dt ê Ÿ ú Ì )in m Õ‡ ° d ONLN dx ê Ì ú )emory G ° d ONLN d} ê ú ) . ˆ ° d ONLN d ê
e code. This ° d ONLN dl fi ä Í ( Á ä makes it very easy to implemen ≥@ ° d ONLN dä fi Íh )åt import libraries a @ ° d ONLN dû fii Íü )S s fragments. ° d ONLN d´ ä ¸ ë ( ˘ äA ∫† ° d ONLN d¨ ë ¸ ≈ ) fragment’s E‡ ° d ONLN d∏ Δ ¸ ¸ )5 data section h† ° d ONLN dƒ ¸ ¸v )6 contains the static data defi ‡ ° d ONLN d‚ w ¸– ){ned by the fragment “¿ ° d ONLN dı – ¸’ )Y. t` ° d ONLN d˜ ’ ¸‹ )A ;† ° d ONLN d¯ › ¸ ) n applica “@ ° d ONLN d ¸ )(- ° d ONLN d ˝ ä § ( äCtion’s data section is typically loaded into the application’s heap t@ ° d ONLN dF ˝• ™ (•. ‡ ° d ONLN dH ˝™ ˚ )An import library’ ´Ä ° d ONLN dZ ˝˚ )Qs ° d ONLN d\
ä
( äYdata section can be loaded into the system heap or into the heap of any application that ° d ONLN dµ ä# ® *
eating mor ∂` ° d ONLN dM$¢0 )0e than one copy of the ° d ONLN dd1 ä=& (: ä&data. This is especially useful for pr ˙ ° d ONLN dä1&=W )ú oviding dif
@ ° d ONLN dï1X=d )2fer Ô¿ ° d ONLN dò1c= ) (ent applications with their own copy of ° d ONLN d¿> äJ ‚ (G äa library’s data. See ° d ONLN d÷> „Jç )Y%“Import Libraries” beginning on page ` ° d ONLN d˚>çJü )™1-50 k@ ° d ONLN dˇ>üJ¬ ) for mor 5¿ ° d ONLN d>√J
)$e details on this. ° d ONLN dP ä\À (Y äEEven though a fragment’s code and data sections can be loaded anywher ` ° d ONLN d_PÃ\ (YÃ e in memory Ó‡ ° d ONLN djP\ )6, ° d ONLN dl] äi ‰ (f äthose sections canno Ω‡ ° d ONLN dÄ] ‰i Ô )Zt b ‡ ° d ONLN dÉ] i ) <e moved within memory once they’ve been loaded. Part of the ° d ONLN døj äv ì (s äpr G ° d ONLN d¡j îvd )
/ocess of loading a fragment into memory is to r Ä ° d ONLN djdv )–&esolve any dependencies it might have ° d ONLN dw äÉ (Ä äupon other fragments. This q ° d ONLN d1wÉ ){pr 8@ ° d ONLN d3wÉ; )
eparation Ë@ ° d ONLN d=w;É ),/involves inserting into part of the fragment’s ° d ONLN dlÑ äê Û (ç ädata section a number o ,Ä ° d ONLN dÉÑ Ùê$ )j f pointers t /¿ ° d ONLN dèÑ$êË )0+o data and code imported by the fragment fr û ° d ONLN d∫ÑËê¯ )ƒom ° d ONLN dæë äùÅ (ö ä9other fragments, as described in the following section. T ° d ONLN d˜ëÅù˜ )˜o avoid having to perform ° d ONLN dû ä™ — (ß äthis fragment pr @ ° d ONLN d"û “™ )H
eparation mor ≈¿ ° d ONLN d/û™≠ )>#e than once, the Operating System r ) ° d ONLN dRûÆ™≈ )ûequir @@ ° d ONLN dWû≈™ )es that a loaded ° d ONLN dh´ ä∑ ∏ (¥ ä
fragment r L ° d ONLN dr´ π∑¶ )/6emain stationary in memory for as long as it is loaded ‹@ ° d ONLN d®´¶∑® )Ì.
≈ H” 4Δ H”
° d ONLN d™ƒ äœ ù (à äNote
ˇ·ˇ‚7^
° d ONLN dØ— ä› ÿ *In the 680x0 envir $Ä ° d ONLN d¡— Ÿ›≈ )O4onment, an application’s code can be unloaded (by th = ° d ONLN dı—≈›Ã )Ïe ° d ONLN d˜› äÈ ª (Ê äMemory M ` ° d ONLN dˇ› ºÈ
)2anager) and later r ° d ONLN d ›È[ )Reloaded into a dif M¿ ° d ONLN d $›[Èg )Mfer 0@ ° d ONLN d '›gÈ¡ ) ent place in memory ∏‡ ° d ONLN d :›¿È≈ )Y. ° d ONLN d <È äı ´ (Ú äThis dif A‡ ° d ONLN d DÈ ¨ı ∏ )"fer $` ° d ONLN d GÈ ∏ı › ) ence in r ë† ° d ONLN d PÈ ›ıù )%*un-time behavior leads to some important r Ù@ ° d ONLN d zÈùıà )¿ estrictions ° d ONLN d Üı ä (˛ ä on stand-alone PowerPC code r √@ ° d ONLN d £ı- )ãesour Ä ° d ONLN d ®ı.] ) ces (called ¸† ° d ONLN d ¥ı]à )/ accelerated ™Ä ° d ONLN d øıâè ), r ÔÄ ° d ONLN d ¡ıèß )esour 7¿ ° d ONLN d Δı®ª )ces) ° d ONLN d À ä
É (
ä9that mimic the behavior of existing kinds of 680x0 code r E‡ ° d ONLN d
Ñ
ú )˙esour é ° d ONLN d
ú
ø ) ces. See ° d ONLN d
ä ‡ ( ä“Executable Resour ˜† ° d ONLN d
$
‡I )Vces” beginning on page ƒ† ° d ONLN d
;
J\ )j1-34 Ä ° d ONLN d
?
]ê ) for details. ,
Zapf Dingbats
° d ONLN d
Nñú )9u
6 H= 47 H= 8 ä8
ˇ·ˇ‚7^
° d ONLN d
P) ä7 ı (3 äImports and Exports ˇˇˇˇˇˇ ‘@ (31
° d ONLN d
e= äI (F äVAs you’ve seen, a fragment (for example, an application) can access the code and data ° d ONLN d
ªJ äVF *
*contained in some other fragment (typicall ø‡ ° d ONLN d
ÂJFVù )ºy an import library) * ° d ONLN d
˘JûV )X by importing that code ° d ONLN d W äc Ë (` äand data. Conversely n ° d ONLN d %W Ác> )], an import library c e` ° d ONLN d :W?cL )Xan ∂¿ ° d ONLN d =WLch )
export ô ° d ONLN d CWicÙ ) code and data for use by other ° d ONLN d cd äpa (m ä1fragments (applications, extensions, or even othe JÄ ° d ONLN d îdbp∞ )ÿr import libraries) &† ° d ONLN d ßd±p⁄ )O . It’s the r n ° d ONLN d ≥d⁄p ))esponsibility ° d ONLN d ¡q ä} — (z äof the linker to r ë ° d ONLN d ”q —}¯ )GCesolve any imports in your application (or other code fragment) to ° d ONLN d ~ ää À (á äexports in som ú ° d ONLN d $~ Àä )Ae import library ¿ ° d ONLN d 4~ä )E8. The linker generates symbols that contain the name of ° d ONLN d lã äó (î äTthe exporting library and the name of the exported symbol and inserts those symbols ° d ONLN d ¿ò ä§ ˇ *
into your linked applicatio l ° d ONLN d €ò § )vn. ˇ= @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-24
)B The PowerPC Native Environment 4 ^ *¿¯
° d ONLN d \ l h Ñ ( e lFigur R¿ ° d ONLN d \ Ñ h ò )e 1-2 @ ° d ONLN d
Figure 1-2 ° d ONLN dÎ ¡ Æ Ã' )B Creating imports in a fragment
° d ONLN d å lò v (ï lW ° d ONLN d å vòü )
@hen your application is launched, the Code Fragment Manager sear ° d ONLN dLå†ò’ (ï†
ches for the ° d ONLN dYô l• Ö (¢ llinker ?‡ ° d ONLN d_ô Ü• ) -generated import symbols and r † ° d ONLN d~ô•è )ëeplaces them with the addr â ° d ONLN dòôè•Ô )xesses of the imported ° d ONLN dƶ l≤ ≠ (Ø lcode or data. T G ° d ONLN dΩ¶ ≠≤
)Ao do this successfully ` ° d ONLN d”¶
≤æ )]&, the Code Fragment Manager needs to fi 3‡ ° d ONLN d˙¶æ≤‹ )¥nd the ° d ONLN d≥ lø Ä (º lappr I@ ° d ONLN d≥ Åø õ )opriat fi@ ° d ONLN d ≥ õø ‡ )e import library ›† ° d ONLN d≥ ·øÑ )F( and load it into memory if it isn’t alr fi` ° d ONLN dC≥Ñøà )£eady in memory Y¿ ° d ONLN dQ≥Ãøı )H . Then, it
ˇ˛ ˇ ˛ˇˇ ˇ ˛˝ ˇˇ ˛ ˇ˛ ˇ˛˛ ˛˙ ˛ˇ˛ ˇ ˛˛ˇ ˛Å Å Å · Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H gÆP 5flÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ/ 'K ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆK 'ã ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉã 'À ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆÀ 'Á ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H gÆT 5‡Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆK 'ã ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H gÆP 5·Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉã 'À ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H gÆT 5‚Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆÀ 'Á ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ˇ" @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
&e . 3 +ä"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ ä'Introduction to PowerPC System Software 4⁄ ä˙ (‡ ä The PowerPC Native Environment
4 Å4w? êÄ Å6w@ M M ! Ä ˇˇˇˇˇˇ Å6w@ Å6w@ $ ?Ä > < " > " " " " ?Ä > " " " >Ä " " > < " " " ?ÄÄÄ " " 0 0 * * , > ?ÄÄÄ Ä Ä $Ä$Ä$Ä ò ` $ * * " * * , > < < $Ä$Ä$Ä " " ? Ä " 0 0 * * > * * , 4 ^ H¿ ° d ONLN d \ ä h ± ( e ä needs to ı@ ° d ONLN d \ ± h Δ )'bind ú` ° d ONLN d
\ « h— )< the imported symbols in your application to the actual addr -† ° d ONLN d I \“ h ( e“ esses, in th ≈` ° d ONLN d U \ h )/e ° d ONLN d W i ä u » ( r äimport library ° d ONLN d e i » u‹ )>>, of the imported code or data. Once the loading and binding o 0 ° d ONLN d £ i‹ u ( r‹ f import ° d ONLN d ¨ v ä Ç π ( ä libraries ar Ò† ° d ONLN d ∏ v π Ç Ω )/e ª@ ° d ONLN d π v æ Çl )' complete, your application can execute k@ ° d ONLN d ‡ vm Ço )Ø.
invalid addr @< ° d ONLN dh]HiQ );es @< ° d ONLN dj]Qi| ) s (namely Ì® ° d ONLN ds]{i )*, ,
Courier ˇˇ[Ñ ∂‘ ° d ONLN du]Äi )kUnresolvedSymbolAddress ˇˇ…, ∂‘ ° d ONLN dç]i )ê) . ° d ONLN dèj äv ⁄ (s äinto your fragmen 4† ° d ONLN d†j €v  )Qt’s {@ ° d ONLN d£j Âv/ )
table of contents TÄ ° d ONLN dµj0vè )K entry for any QuickT / ° d ONLN d jèv• )_ime r ˙ ° d ONLN dœj•v )outines or data items.
Ñ Hí 4Ö Hí
° d ONLN dÊÑ vé ~ (å vs
° d ONLN dÁÖ äç ì (ã äW úÄ ° d ONLN dËÖ ìç æ ) ARNING
ˇ·ˇ‚7^
° d ONLN dÔê äú ê (ô äY @Ä ° d ONLN dê êú Ÿ )ou should alway ¿ ° d ONLN dˇê ⁄ú )Js check to see t ,‡ ° d ONLN dêú~ )Ahat any imports declar ° d ONLN d%ê~ú∑ )ced as soft by ° d ONLN d3ú ä® √ (• ä your softwar c ° d ONLN d?ú √® € )9e wer í` ° d ONLN dDú €® )e successfully r D ° d ONLN dTú ®v )Cesolved at load time 8† ° d ONLN dhúw®Ç )Y. T s` ° d ONLN dkúÅ®ƒ )
rying to access ° d ONLN d{® ä¥ « (± äcode or data r V` ° d ONLN dâ® «¥ ◊ )=efer Ä ° d ONLN dç® ÿ¥ )enced by an unr ¯¿ ° d ONLN dú® ¥º )F$esolved soft import will cause your ° d ONLN d¿¥ ä¿ ´ (Ω äsoftwar ‰¿ ° d ONLN d«¥ ´¿ ◊ )! e to crash.
WÄ ° d ONLN d”∑ ›ø ‰ )2s
. ° d ONLN d’≈ ä— ˆ (Œ äFor most system softwar R` ° d ONLN dÏ≈ ˆ—k )l e services, you can use the R` ° d ONLN d≈k—ï )uGestalt R` ° d ONLN d≈ï— )* function to determine if the . ° d ONLN d-“ äfiR (€ ä/necessary code or data is available in the curr ~ ° d ONLN d\“Rfi¶ )»ent operating envir @ ° d ONLN do“ßfi )Uonment. Note that this ° d ONLN dÜfl äÎ ≈ (Ë äis not a new r † ° d ONLN dîfl ≈Î ‹ );equir ¸‡ ° d ONLN dôfl ‹ÎÎ );ement and should not cause you to change your existing sour J† ° d ONLN d‘flÏΘ (ËÏce . ° d ONLN dÿÏ ä¯ (ı ä code; existing 680x0 softwar R` ° d ONLN dÙϯX )}e should also call R` ° d ONLN dÏX¯Ç )QGestalt R` ° d ONLN dÏǯ¶ )* to ensur $¿ ° d ONLN d϶¯ )$e that needed system ˇˇaÚ ° d ONLN d,˘ ä ≠ ( äsoftwar R` ° d ONLN d3˘ ≠ ‚ )#
e services ar ˧ ° d ONLN d@˘ ‚ )5 e available. Jñ ° d ONLN dL˘D )8 When no ˇ˛%÷ pl ° d ONLN dU˘Dn )*Gestalt ˇˇaÚ pl ° d ONLN d\˘n )*+ selector exists to test for the existence . ° d ONLN dá ä Œ ( äof a particular r @ ° d ONLN dò œà )E*outine or data item, you can check for unr ¿ ° d ONLN d¬àÒ )πesolved soft imports by . ° d ONLN d⁄ ä „ ( äcomparing the addr R` ° d ONLN dÏ „ ; )Yess of the import to R` ° d ONLN d ; À )XkUnresolvedSymbolAddress R` ° d ONLN d À Œ )ê. R` ° d ONLN d Œ – ) R` ° d ONLN d – ) Listing 1-4 R` ° d ONLN d & )0 . ° d ONLN d ' ä, ¯ () äillustrates this technique.
O HW 4P HW "P H_
ˇ·ˇ‚7^
° d ONLN d CE äP ∂ *$ Listing 1-4 ° d ONLN d OE ŒP ” )DT ° d ONLN d PE ”PW )"esting for unresolved soft imports
. ° d ONLN d t_ äkJ (h ä extern int printf (char *, ...); ° d ONLN d ïm äy ú *... ° d ONLN d ô{ äá fi *if (printf == ° d ONLN d ß{ fián )TkUnresolvedSymbolAddress ° d ONLN d ø{nát )ê) ° d ONLN d ¬â úïÄ (í ú&DebugStr("\printf is not available."); ° d ONLN d Èó ä£ ¢ († äelse ° d ONLN d Ô• ú±8 +printf("Hello, world!\n"); ˇ ∏ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-26
)B The PowerPC Native Environment 4 ^ *¿¯
° d ONLN d \ l hR ( e l4See the description of the MakePEF tool in the book Ȇ ° d ONLN d 4 \R hÇ )Ê Building Pr À ° d ONLN d ? \Ç hÊ )0ograms for Macintosh W ` ° d ONLN d U \Á hÙ )eith ° d ONLN d Y i l u í ( r lPowerPC “† ° d ONLN d ` i í uq )&5 for exact details on how to specify imports as soft.
ì * ö¯ 4 î * ö¯ ï l ï¯
ˇ·ˇ‚7^
° d ONLN d ñ Ü l î Ñ ( ê lThe J¿ ° d ONLN d ö Ü Ñ î ã )T J¿ ° d ONLN d õ Ü ä î · )able of Contents ˇˇˇˇˇˇ ‘@ ( êÒ1
ess book. †@ ° d ONLN dhJGVN )*A ⁄‡ ° d ONLN diJNV• ) fragment’s table of ° d ONLN d~V lb} (_ lBcontents is private to the fragment itself and exists solely to pr 1† ° d ONLN d¿V~bô (_~ovide ° d ONLN dΔb ln2 (k l.external linkage for the code in the fragment. ,
Zapf Dingbats
7@ ° d ONLN dıe8m> )Ãu
° d ONLN d˜s l s (| lA ∫† ° d ONLN d¯s sÍ )X fragment’s table of contents also contains pointers to the fragment’s own static data. ° d ONLN dPÄ låO (â l3Because the code and data sections of a fragment ar í ° d ONLN dÉÄOå∫ )„e usually loaded into dif ¿ ° d ONLN dúÄªå« )lfer ‰@ ° d ONLN düÄΔå÷ ) ent ° d ONLN d£ç lô Δ (ñ llocations in memory † ° d ONLN d∂ç Δô‚ )Z?, and because they must both be position-independent, the code ° d ONLN dıö l¶ Á (£ lsection needs a method of fi æ† ° d ONLN dö Á¶å ){%nding its own data, such as data addr u¿ ° d ONLN d6ö綔 )¶essed by global ° d ONLN dFß l≥ Ï (∞ l variables. Global variables ar £¿ ° d ONLN ddß Ï≥ )Äe addr ȇ ° d ONLN djß≥/ ) essed thr k† ° d ONLN dsß0≥Ÿ )('ough the fragment’s table of contents. ° d ONLN dö¥ l¿ v (Ω lW Û` ° d ONLN dõ¥ u¿= ) .ithin the compiled code of your application, r ` ° d ONLN d…¥>¿N )…efer ≥Ä ° d ONLN dÕ¥N¿È )$ences to global variables appear as ° d ONLN dÒ¡ lÕ Å ( lindir ‡ ° d ONLN dˆ¡ ÇÕ î )ect r ƒ ° d ONLN d˚¡ îÕ § )efer p@ ° d ONLN dˇ¡ •Õ ÿ ) ences via of ¨Ä ° d ONLN d ¡ ÿÕ] )3!fsets into the table of contents. ˇˇÀF ° d ONLN d-” lflÊ (‹ lUOf course, for this scheme to work, the code section of a fragment needs to know wher f ° d ONLN dÇ”Êfl¯ (‹Êe in ° d ONLN dᇠlÏ ¶ (È l memory its T C¿ ° d ONLN dì‡ ßÏ );OC begins. The addr Δ ° d ONLN d¶‡Ï3 )[ ess of the T #Ä ° d ONLN d≤‡4Ï )2)OC cannot be compiled into the fragment; ° d ONLN d€Ì l˘ ∂ (ˆ linstead, the addr ¯` ° d ONLN dÏÌ ∂˘ Á )J ess of the T U‡ ° d ONLN d¯Ì ˢ' )2OC of the curr ûÄ ° d ONLN dÌ'˘È )?,ently executing fragment is maintained in a ° d ONLN d2˙ l o ( lr E ° d ONLN d3˙ p ¬ )egister on the micr W† ° d ONLN dF˙ ¬ — )Ropr î@ ° d ONLN dI˙ — Ò )ocessor h` ° d ONLN dP˙ Ò ) . Curr > ° d ONLN dV˙ ! )ently w@ ° d ONLN d[˙ Ñ ), the general-purpose r ∂` ° d ONLN dr˙ј )degister GPR2 is dedicated ° d ONLN då l ≠ ( lto serve as the ª` ° d ONLN dú ≠ ≥ )AT K ° d ONLN dù ≥3 ) able of Contents Register (R Ä ° d ONLN dπ3O )ÄTOC). ‡ ° d ONLN dæOß ) It contains the addr |‡ ° d ONLN d”ßı )Xess in memory of ° d ONLN d‰ l Õ ( lthe beginning of the T ´† ° d ONLN d˙ Õ )aOC of the curr Ù@ ° d ONLN d } )?ently executing fragment. ° d ONLN d "& l2% (/ l*It’s easy to see how a code fragment can fi ` ° d ONLN d M&&2‡ )∫+nd its own global data. It simply adds the ° d ONLN d x3 l? ¨ (< lcompiled-in of ` ° d ONLN d Ü3 ≠?L )A&fset of a global variable within the T ˆ‡ ° d ONLN d ¨3K?ç )ûOC to the addr ˚Ä ° d ONLN d ∫3ç?æ )B ess of the T Y ° d ONLN d Δ3ø?– )2OC ° d ONLN d …@ lL º (I lcontained in the R ` ° d ONLN d €@ ºL ¬ )PT rÄ ° d ONLN d ‹@ ¬L Ì ) OC. The r f ° d ONLN d Â@ ÌL3 )+esult is the addr ‡ ° d ONLN d ˆ@4LO )Gess of *‡ ° d ONLN d ˝@OLÑ )
a pointer to í¿ ° d ONLN d
@ÑL™ )5 the desir ø‡ ° d ONLN d
@™LÕ )&ed data. ° d ONLN d
R l^ ≤ ([ lIt’s slightly mor [¿ ° d ONLN d
-R ≤^Ô )FGe complicated to see how a code fragment can execute an external piece ° d ONLN d
t_ lk ë (h l of code. 6 ° d ONLN d
}_ ëk√ )%HAs it does with global data, the linker accesses external code via an of r` ° d ONLN d
Figure 1-3 ° d ONLN d \ Ã g “ )BA 0 ° d ONLN d \ “ g ) transition vector
à H⁄ 4à HŸ ° d ONLN d À ä÷ ù (” äNote
ˇ·ˇ‚7^
° d ONLN d %◊ ä„Õ *
KStrictly speaking, a transition vector can contain any number of pointers, ° d ONLN d p„ äÔ … * as long as ther ⁄¿ ° d ONLN d „ …Ô Ÿ )?e ar È` ° d ONLN d É„ ŸÔ1 )e at least two. The fi ˛ ° d ONLN d ô„1Ô≤ )X rst pointer is always the addr *‡ ° d ONLN d ∑„≥ÔŒ )Çess of ° d ONLN d æÔ ä˚ û (¯ äthe r ¢` ° d ONLN d √Ô û˚ƒ )Doutine being called, and the second pointer is always a value to be ° d ONLN d˚ ä_ ( ä1loaded into GPR2 prior to the execution of that r ç@ ° d ONLN d8˚_¥ )’outine. The second ° d ONLN dK äÖ ( ä9pointer in a transition vector can serve any purpose appr `` ° d ONLN dÑÖ¬ )˚opriate to the ° d ONLN dì ä ™ ( äcalled r Î` ° d ONLN dõ ™ * ) outine. In the PowerPC envir \† ° d ONLN d∑+ √ )Å onment for Macintosh computers, ° d ONLN d◊ ä+@ (( ä)the second pointer is almost always the T ôÄ ° d ONLN d @+f )∂OC addr ‡ ° d ONLN d g+Ω )'ess of the fragment ° d ONLN d+ ä7 Ï (4 äcontaining the called r ƒ‡ ° d ONLN d2+ Ï76 )boutine. However ì‡ ° d ONLN dA+67w )J, the callee is fr ¿ ° d ONLN dS+x7± )Bee to use the ˇˇÏñ ° d ONLN da7 äCy (@ ä8second pointer in other ways, if this is deemed useful. \ ° d ONLN dô7zCÄ )Y –‹ ° d ONLN dö7CÕ )our development ° d ONLN d™C äO± (L äCsystem’s compiler ultimately determines the size and contents of a ° d ONLN dÌO ä[ “ * transition vector j† ° d ONLN d˛O “[ ‘ )H. ,
Zapf Dingbats
͆ ° d ONLN d R ŸZ fl )u
° d ONLN d` äl ë (i äA ∫† ° d ONLN d` ël ô ) T -¿ ° d ONLN d` öl ) OC entry for an external r ¸¿ ° d ONLN d ` l± )q(outine points to a transition vector lar } ° d ONLN dG`≤l˜ )ßgely so that the ° d ONLN dXm äy ≠ (v ä calling r N‡ ° d ONLN dam Æy Û )$outine can set u £ ° d ONLN dqm Ûy ˚ )Ep % ° d ONLN dsm ¸y ) an vÄ ° d ONLN dvm y )
R Δ ° d ONLN dwmy )T π@ ° d ONLN dxmy¢ ) OC with the called fragment’s T ` ° d ONLN dóm£y )éOC value. Then, when ° d ONLN d¨z äÜ ∫ (É ä the called r H¿ ° d ONLN d∏z ªÜ! )1outine exits, the caller r ¿ ° d ONLN d“z"Ü7 )gestor à@ ° d ONLN d◊z7ÜY )es the R ª‡ ° d ONLN dflzYÜ_ )"T Ø ° d ONLN d‡z_Ü )*OC to its original value, pointing to the ° d ONLN d
á äì ê (ê äT s ° d ONLN d á êì∫ )EOC of the calling fragment. This kind of function call is known as a ì ° d ONLN dPá∫ìˇ (ê∫cross-TOC call. ˙ ° d ONLN d_áˇì )E ° d ONLN d`î ä† º (ù ä During a cr µ ° d ONLN dkî º† ” )2oss-T Ά ° d ONLN dpî ”† )IOC call, GPR12 is assumed to point to the transition vector itself; this ° d ONLN dπ° ä≠ (™ ä convention allows the called r ç ° d ONLN d◊°≠û )Ñ!outine to access any additional fi Ä ° d ONLN d˘°ü≠¸ )ëelds in the transition ° d ONLN dÆ ä∫ ‚ (∑ ävector beyond the fi ∑¿ ° d ONLN d$Æ ‚∫ )Xrst two.
˛êêê @ˆ v à ∂~ ' Å Å Å ã Å Å Å ã Å Å Å ã e ÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏ]ÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÎÏÅ È ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÎÎÅ Í ÎÅ Å ß ÏÎÅ Í ÎÅ Å ß ÎÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÏÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÎÎÅ Í ÎÅ Å ß ÏÎÅ Í ÎÅ Å ß ÎÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÏÎÅ Í ÏÅ Â ˇÌ ˇ ˇ ˇ ˇÅ ‡ ÎÏÅ Í ÎÅ Â ˇÌ ˇ ˇ˛ ˇÅ ‡ ÎÎÅ Í @ ÎÅ Â ˛ˇ ˇ˛ ˛ˇ ˇˇ ˇˇ ˛ˇ ˇ ˇ ˛ˇ ˇˇ ˛ˇ ˇˇ ˇ ˇˇÅ Ò ÏÎÅ Í ? ÎÅ Â ˇˇ ˇ ˇ ˇ ˇˇ ˇ ˇ˛ ˇ ˇ ˇ ˇ ˇˇ˝ ˛ˇ ˇ ˇÅ ÎÎÅ Í A ÏÅ Â ˇˇ ˇ ˇ ˇ ˇˇ ˇ ˇ˛ ˇ ˇ ˇ ˇ ˇˇ ˇˇ ˇˇ ˇ ˇÅ ÎÏÅ Í = ÎÅ Â ˇˇ ˇ ˇ ˛ˇ ˇˇ ˇ˛ ˇˇ ˇ ˇ ˛ˇ ˇ˛ ˝ˇ˛ ˇÅ Ô ÏÎÅ Í ÏÅ › ˇfl ˇÅ Ô ÎÏÅ Í ÎÅ › ˇ‡ ˇÅ Ó ÎÎÅ Í ÎÅ › ˇÅ à ÏÎÅ Í ÎÅ ó ˇˇì ÎÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Ïâ ¸ˇî ˝ˇï ÎÏÅ Í ÎÜ ˇˇí ˇˇï ÏÎÅ Í Ïá ˇˇë ˇˇï ÎÏÅ Í Îá ˇë ˇˇî ÎÎÅ Í Îà ˇˇí ˛ˇî ÏÎÅ Í Îâ ˇˇë ˇˇì ÎÎÅ Í Ïâ ˇë ˇˇí ÎÏÅ Í Îä ˇˇí ˛ˇí ÏÎÅ Í Ïã ˇˇë ˇˇë ÎÏÅ Í Îã ˇë ˇˇê ÎÎÅ Í Îå ˇˇí ¸ˇí ÏÎÅ Í Îå ˝ˇê ˇí ÎÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Ïâ çˇÏ ˙ˇØ ÎÏÅ Í Îâ ˇê ˇˇÊ ˛ˇ± ÏÎÅ Í Ïâ ˇê ˇˇ‰ ˇ± ÎÏÅ Í Îâ ˇê ˇˇ‰ ˇˇ≤ ÎÎÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÏÎÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÎÎÅ Í Ïâ ˇê ˇˇ„ ˇ≤ ÎÏÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÏÎÅ Í Ïâ ˇê ˇˇ„ ˇ≤ ÎÏÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÎÎÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÏÎÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÎÎÅ Í Ïâ ˇê ˇˇ„ ˇ≤ ÎÏÅ Í Îâ ˇê ˇˇ„ ˇ≤ ÏÎÅ Í òň @ Ĉ H H gÆL 5‰Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆí àÆ~ ' Ïá ˇˇë ˇˇï ÎÏÅ Í Îá ˇë ˛ˇï ÏÎÅ Í Ïà ˇˇë ˇˇî ÎÏÅ Í Îâ ˇˇë ˇˇì ÎÎÅ Í Îâ ˇë ˛ˇì ÏÎÅ Í Îä ˇˇí ˛ˇí ÎÎÅ Í Ïã ˇˇë ˇˇë ÎÏÅ Í Îã ˇë ˛ˇë ÏÎÅ Í Ïå ˇˇí ˛ˇê ÎÏÅ Í Îå ˝ˇî ¸ˇí ÎÎÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÏÎÅ Í Ïâ ˇê ˇˇì ÎÏÅ Í Îâ ˇê ˇˇì ÎÎÅ Í Îâ ˇê ˇˇì ÏÎÅ Í ÎÅ Å ß ÎÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÏÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÎÎÅ Í ÎÅ Å ß ÏÎÅ Í ÎÅ Å ß ÎÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÏÎÅ Í ÏÅ Å ß ÎÏÅ Í ÎÅ Å ß ÎÎÅ Í ò @ @ˆ @ˆÆ àÓ~ ?◊ˇ ˛Ì ?◊ˇ ˛Ì ◊ˇ ˛Ì ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ˝ ¯¯Ë‡èà ˝ DEHà ˝ DF Pà ˝ àä úà ˝ Ùà ˝ ÄÑ#à‡ÇÃ
˛êêê @ˆJ àä~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H gÆT 5ÌÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉä à ~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H gÆL 5ÓÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆ àÊ~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ò @ @ˆ @ˆÊ à&~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ @ Ĉ @ Ĉ& àf~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ò @ Ä úˆ Ä úˆf àÇ~ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ òň @ˆ H H gÆT 5ÔÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ˆÊ à&~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň @ Ĉ H H gÆL 5Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ĉ& àf~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã òň Ä úˆ H H gÆT 5ÒÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä úˆf àÇ~ ' Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã Å Å Å ã ˇ Ä @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 * \¯ , Palatino
&e . 3 +l"CHAPTER à )>1 , Helvetica
ˇˇ—Ú ˇÆ ( @ l'Introduction to PowerPC System Software 4⁄ *˙¯
(‡ *1-28
)B The PowerPC Native Environment 4 ^ *¿¯
° d ONLN d \ l h r ( e lT µ¿ ° d ONLN d \ q h Ω )o access data stor Á` ° d ONLN d \ Ω h9 )L ed in another fragment, ther F¿ ° d ONLN d / \: h„ )}+e is no need for the caller to install the ° d ONLN d Z i l u r ( r lT s ° d ONLN d [ i r u ò )OC addr ‚Ä ° d ONLN d b i ò u* )&"ess of the other fragment in the R ° d ONLN d Ñ i+ u1 )ìT Û@ ° d ONLN d Ö i0 uÄ )OC. Instead, the T À@ ° d ONLN d ó iÄ uÁ )POC entry of the calling ° d ONLN d Ø v l Ç– ( lRfragment contains a pointer to the external data, in exactly the same way that a T Ç¿ ° d ONLN d v– Ç· ( –OC ° d ONLN d É l èØ ( å lKentry for global data in the same fragment contains a pointer to that data. ° d ONLN dP ï l °< *1In short, a fragment’s table of contents contains ,
